Archive for Декабрь, 2009

Текущее состояние внедрения SAP в банках

Четверг, Декабрь 31st, 2009

© sapbanking.org

Какая текущая ситуация по внедрению SAP в банках на территории exUSSR? Где в банках есть SAP?  Какие компании имеют экспертизу по SAP for Banking? Где найти специалистов по SAP для внедрения в банках?

Ответить на эти вопросы предназначен текущий пост. Он будет постоянно обновляться по мере получения новой информации. Информация не претендует на полноту и основывается как на личной информации, так и на открытых источниках. Если есть, что дополнить или исправить – пишите на sapforbanking@gmail.com или добавляйте в комментарии к этой статье.

Для начала – ссылка на видение решения SAP for Banking самой компанией SAP AG и описание новейшего решения для банкой от компании SAP AG, основанного на SOA. А также описание отраслевого решения.
А дальше – информация по ситуации в конкретных банках.

Можно сказать только одно. Полноценное внедрение SAP for Banking есть только в Укрсиббанке. Остальные банки внедрили один или несколько модулей или находятся на пути к внедрению.  Полноценным внедрением называю ситуацию, когда банк использует SAP как операционный день банка, проводя в SAP все транзакции.

Современное решение Banking services from SAP 7.0, имеющее более общее название SAP for Banking предназначено для максимального покрытия потребностей банка.  Account Management (FS-AM) - модуль ведения счетов, рамочных договоров, проведения транзакций, имеет гибкую настраиваемую систему финансовых условий и расширения функционала под требования отдельного банка, систему ведения карточек, создания банковских выписок, получения баланса, ввода платежный поручений и многое другое.  Также включен функционал ведения кредитов и срочных депозитов.  Это ядро системы.  Business Partner for Financial Services (FS-BP) Деловой Партнер позволяет построить единую базу клиентов, доступную из всех других модулей SAP.  Collateral Management (FS-CMS) – это модуль залогов, который интегрируется с кредитным модулем, позволяющему учитывать и вести состояние обеспечения по активам банка.   Bank Analyzer (FS-BA) – это базис для системы управленческой и регуляторной отчетности, консолидации данных, ведения лимитов (Limit Management). Одной из целей этого модуля завлено построение отчетности по стандартам Basel 2.

Проблема внедрения SAP в банках усугубляется тем, что на территории СНГ консалтинг может дать экспертизу только по обычным промышленным модулям, таким как модули кадрового учета, учета внутрихозяйственной деятельности. По самому же банкингу экспертиза есть, но рассеяна по проектам в виде отдельных людей, имеющих необходимый опыт. Часть из которых  – фрилансеры. Но  ни один консалтинг не имеет полноценной компетенции.  А если какой-либо консалт подпишется под внедрение функциональности SAP for Banking или какой-либо значимой части, к примеру Bank Analyzer (FS-BA) , то это будет подразумевать сбор с рынка людей, который хоть что-то видели по этому направлению, потом быстрое обучение внутренней команды (качество знаний не выдержит никакой критики) и дальнейшее изучение этого функционала и приобретение экспертизы на самом проекте внедрения. Что, в общем-то грустно, т.к. очень высокие риски, что такой проект “не взлетит”. В любом случае это будет тренировка новой команды консалтера на клиенте на новом функционале.

Укрсиббанк ukrsibbank.com BNP PARIBAS GROUP, Украина

В 2003 г. начался пилотный проект. С 2004 по 2005 г. проектные работы вплоть до продуктивного старта. Полнофункциональное внедрение FS-BP, FI (практически вся линейка), HR, FS-CML, FS-CMS, FS-CFM, FS-AM(3.0), BW. Вся сеть – более 800 отделений работают в централизованной системе с единым пулом счетов, договоров, централизованным ведением Делового Партнера. Покрыты все более-менее крупные города Украины.  Старт небольшой внутренней командой с привлечением точечного внешнего консалтинга, что позволило оставить всю экспертизу по решению в среде банковских специалистов. И, видимо, упор проекта на внутреннюю команду позволил избежать “съедания” бюджетов консалтом и позволил проекту успешно запуститься. Куратор проекта SAP-Украина.

Впоследствии в банке был внедрен SAP Solution Manager и SAP Business Objects.

Пресс-релиз пилота здесь.

Update от 10.09.2010.  Внедрен юридический модуль для департамента взыскания долгов.  Автоматизирован документооборот кредитных дел. Информация здесь.

Центр-Инвест Банк г. Ростов-на-Дону centrinvest.ru Акционеры: ЕБРР (27,45%), Немецкая корпорация инвестиций и развития DEG (22,45%), В.В. и Т.Н. Высоковы (17,85%), Firebird Investment Fund (9.90%), Erste Bank (9,80%), Renaissance Capital (8,15%), Raiffeisenlandesbank Oberцsterreich Aktiengesellschaft (3,58%).

Запущены в продуктивную эксплуатацию хранилище данных на базе SAP BW для регуляторной и аналитической отчётности, интеграционное решение SAP PI, модуль SAP HR (HCM).

update 20.10.2012 Центр-инвест банк принимает участие в локализации SAP for Banking. Также упоминается проект построения регуляторной отчётности на SAP BW, который делал с коллегами в банке от компании ОТР-2000. Материал здесь.

 

Промсвязьбанк, psbank.ru Акционеры ЕБРР 11,7457%, Коммерцбанк 15,3199, остальное Промсвязьбанк Капитал 72,9344

Идет постоянное наращивание компетенции в SAP, усиление внутренней команды. Есть тенденция переноса части функционала из других подсистем на SAP. Строится хранилище данных. Интересное интервью с директором Департамента информационных технологий.

Проекты:
Внедрено хранилище данных SAP BW – Главная книга, Деловой партнер, Активы и Пассивы (Кредиты, факторинг, акредитивы и гарантии, ценные бумаги, депозиты).
Оптимизация работы корпоративного блока, ссылка здесь. Внедрение системы контроля сметы АХР ссылка здесь.
Интеграция ОДБ “Новая Афина”, SAP R/3 и Documentum, ссылка здесь.  Внедрение SAP XI,  ссылка здесь.
Проект по созданию и внедрению корпоративного шаблона системы управления персоналом в части базовой функциональности в пилотной зоне (Головной офис и 2 филиала);
Проект по разработке дополнительной функциональности по требованиям клиента. Ссылка здесь.
Внедрение системы управления персоналом на базе SAP ERP HCM во всех филиалах, ссылка здесь.
Также искали специалиста по SAP FI-AA.

Банк Уралсиб bankuralsib.ru

Проекты:

2005 г. Финансовая корпорация «УРАЛСИБ» , компании SAP и IBS объявляют о завершении проекта по созданию автоматизированной системы управления персоналом и структурой ФК «УРАЛСИБ». Это самый масштабный в России проект по внедрению решения mySAP ERP НСM в финансовом секторе.
Проект SAP BI IP.
2009 г. Система управления нормативно-справочной информацией (НСИ) на платформе SAP Netweaver (SAP MDM), ссылка здесь.

Уральский банк реконструкции и развития (УБРР) ubrr.ru

История успеха здесь. В описании щедро упоминается аббревиатура “SAP for Banking”, но фактически есть информация о внедрении FI-FM (бюджетирование),FI-CO (контроллинг), HR, SAP-CRM, SAP-BW и даже SAP-Workflow. Также упонимается, что в рамках первого этапа проекта введены в действие компоненты “Управление финансами”, “Стратегическое управление банком” (видимо SEM), “Управленческий учет”, “Бухгалтерский учет” и SAP-BW. Но нигде не упоминается о внедрении транзакционной системы.
Текущее состояние проекта в УБРР – неизвестно.

update от 03.02.2011 осуществлен переход на SAP CRM 7.0.

update от 27.02.2012 искали разработчика для:
-Интеграция модулей SAP R3 (MM, FI, CRM) с АБС банка.
-Реализация проекта Единого рабочего места на базе SAP CRM.

Национальный банк Украины (НБУ) bank.gov.ua

Было много попыток внедрить SAP в НБУ. Последняя декларируется, как успешная.

Проекты:
Информационная система для управления недвижимым имуществом ссылка здесь. Cоздание информационной системы управления инвестициями на базе решений SAP на основе фунуциональностей PS, MM, FI, CO, FI-AA, PSM-FM, DMS, BW, BW-BPS, ссылка здесь.

Update 12.08.2010 Проведено архивирование информации. Информация здесь.

Ханты-Мансийский Банк khmb.ru

Проекты:
Создание системы формирования управленческой отчетности для проведения общего, детального и сравнительного анализа деятельности банка. Проектирование системы началось “сверху вниз”с создания основных отчетов: «Баланс банка», «Отчет о прибылях
и убытках», «Отчет об эффективности использования активов и пассивов». История успеха здесь. Проект продолжает развиваться в сторону регуляторной отчетности.

Судя по информации от одного из коллег проект вышел на завершающую стадию.

В декабре 2012 года искали ведущего аналитика BI для доработки корпоративного хранилища. Был желателен опыт создания управленческой отчётности и МСФО.

 

АФ Банк (Башкортостан) afbank.ru

Проект стартовал во втором квартале 2008 г., а ввод системы в продуктивную эксплуатацию состоялся уже через 9 месяцев. В рамках проекта были автоматизированы административно-хозяйственная деятельность, бухгалтерский учет, управленческий учет и планирование бюджета; внедрены следующие функциональности – SAP FI («Управление Финансами»), SAP ММ («Управление материальными потоками»), SAP FI-AA («Учет основных средств»), SAP СО («Контролинг и учет затрат»), SAP FM («Бюджетирование»). Реализовано параллельное ведение главной книги в системе Т24 (АБС) и SAP на ежедневной основе.

 

КБ СДМ БАНК sdm.ru

Проекты:
Проект построения системы управленческой и финансовой отчетности на платформе SAP BI ссылка здесь. История успеха здесь. Также внедрено BW-BPS.  Этот проект – хороший пример построения управленческой отчетности банка и МСФО на платформе SAP BW/BI. Была собрана, обработана, консолидирована, обогащена информация из нескольких отдельных подсистем банка, построена сделочная модель, витрина данных. Построены отчеты, позволяющие оценивать работу банка в разрезах продуктов, подразделений и проч.

ОАО Банк “Петрокоммерц pkb.ru

В 2006г. был объявлен старт проекта внедрения SAP-ERP, SAP-CRM и SAP-BW. Декларировалось внедрение единой системы управления взаимоотношениями с клиентами, ссылка здесь. О результатах проекта информации нет.

Национальный банк “ТРАСТ” trust.ru

История успеха здесь.  Список функционала: «Управление персоналом (SAP HCM), SAP Learning Solution, SAP Payroll. Около 100 пользователей.

Проекты:
Внедрение системы управления административно-хозяйственной деятельностью и систему управления персоналом в многофилиальной финансовой структуре, ссылки здесь.
Проект по внедрению функциональности “Управление по целям” на базе SAP ERP HCM. Упоминается здесь.

update 24.06.2012  Банк Траст отказывается от SAP ERP HCM?

 

Халык Банк (Народный банк Казахстана), halykbank.kz, численность сотрудников более 10 тыс. человек.

Проекты:
Проект внедрения системы управления производственно-хозяйственной и финансово-экономической деятельностью на базе решения SAP ERP. Одной из целей проекта названо внедрение централизованного хранилища данных на базе SAP-BW. Ссылка здесь.
Внедрение модуля “Расчет заработной платы”, ссылка здесь. Также упоминается про внедрение модулей “Планирование затрат по персоналу” и “Управление бюджетом расходов на персонал”.

update от 27.02.2012 Искали специалистов по SAP ERP со знанием учета ахд в банках.

Home Credit Bank homecredit.ru

По этому банку есть 2 близкие по смыслу новости:
IDS Scheer внедрила SAP в Home Credit Bank

GMCS автоматизировала административно-хозяйственную деятельность банка «Хоум Кредит»

Оба пресс-релиза относительно автоматизации АХО в одном и том же банке разными подрядчиками.

В декабре 2010 г. искали ABAP разработчика на FI,FM,MM,CO в т.ч. и на фриланс.

В декабре 2012 года искали разработчика под FI (FI-AA, FI-FM) – MM – RCM- SRM.

В декабре 2012 года компания SAPRUN сообщила о внедрении модуля SAP RCM для автоматизации документооборота.

ЗАО Банк “ВТБ24″  vtb24.ru

Проекты:

Автоматизация административно-хозяйственной деятельности. Как ожидается, результаты данного проекта позволят «ВТБ24»: вести учет товарно-материальных ценностей по единым правилам для всех подразделений банка в едином информационном пространстве; централизовать ведение основных данных по материальному учету (справочники товаров, услуг, контрагентов и др.); получать единую отчетность по хозяйственным операциям в условиях развитой филиальной структуры банка; уменьшить нагрузку на АБС банка за счет вывода модуля учета основных средств в SAP ERP.  Update 21.02.2012 искали MM и SD консультантов в штат.

Проект по внедрению системы по управлению персоналом на базе SAP ERP HCM . Проект реализуется совместной командой специалистов ВТБ 24 и компаний GMCS, MOLGA и REDLAB. Команда со стороны банка сформирована из представителей управления персонала и корпоративного развития, управления бухгалтерского учета и отчетности, департамента информационных технологий и департамента сети. Генеральным подрядчиком проекта выступает GMCS, которая обеспечивает выполнение и координацию работ по автоматизации деятельноcти HR-управления банка. Эксперты компаний MOLGA и REDLAB осуществляют разработку архитектуры решения и внедрение функциональных модулей системы. Уже отчитались об успешном завершении проекта.

Отсюда   Банк ВТБ расширил получение оперативной и сводной аналитической информации по объемным показателям на 68% в разрезе продуктов и на 96% в разрезе клиентов, благодаря использованию решений SAP.

update 30.08.2013  ВТБ24 внедряет систему бюджетного планирования  Ссылка

Сбербанк России, sbrf.ru

По состоянию на 02.12.2010 идет тендер по выбору подрядчика по внедрению функциональности SAP HR HCM.Информация здесь.  Как говорится в конкурсной документации, в HCM будут автоматизированы все HR-функции «Сбербанка»: подбор и найм персонала, оценка работников, управление эффективностью их работы, обучением, командировками, льготами, карьерой и преемственностью. Кроме того, расчет заработной платы, планирование затрат и управление вознаграждениями тоже должны перейти в новую систему.
Специалисты из компании SapRun внедряют систему планирования\бюджетирования.
update 14.12.2011 отсюда

Из них выделяется прежде всего масштабная программа по внедрению ERP-системы в Сбербанке. Первый проект программы — «Бюджет расходов и затрат ЦА Сбербанка» — уже находится в продуктивной эксплуатации. Стартовало внедрение проектов по управлению внутрихозяйственной деятельностью, созданию единой системы управления персоналом и системы управления недвижимостью.

Возможно на этой площадке будет всё-таки сделано полнофункциональное внедрение SAP for Banking.

В 2013 году был внедрен SAP HR «Подбор персонала» – модуль по рекрутменту.

РосСельхозБанк rshb.ru

Информации нет. В январе 2010 искали специалиста для: сопровождения системы SAP HR, находящейся в промышленной эксплуатации; поддержки пользователей по функциональностям «Администрирование персонала», «Управление временными данными», «Организационный менеджмент»; настройка системы (модули PA/PD/PT/PY);

По всей видимости, внедрен только модуль SAP-HR.

Тройка Диалог

Проекты:
С 2007 г. проект по внедрению решения для управления персоналом в финансовых организациях SAP ERP HСM, ссылка здесь.

АСБ Беларусьбанк  belarusbank.by

Попытка заменить решением SAP for Banking старую децентрализованную систему.  Пресс-релиз здесь.  Старт проекта в 2006 г.  Известные модули FS-DM, FS-CML и, видимо, FS-BP.

В данный момент проект находится в вялотекущей фазе.

ERSTE банк, Украина, Киев erstebank.ua

Внедрены FI, CO , HR, HR-PY.  Сейчас переход проекта в сапорт.

АО «Цеснабанк», Казахстан tsb.kz

В 3 квартале 2009 года в АО «Цеснабанк», представленного 18 филиалами и порядка 70 пунктами обслуживания клиентов в 23 областных и региональных центрах Казахстана, стартовал проект внедрения решений SAP ERP. В рамках проекта планируется автоматизировать административно – хозяйственную деятельность банка, бухгалтерский учет, управленческий учет и планирование бюджета. Результатом проекта станет создание единого информационного пространства для всех подразделений банка, включая всю филиальную сеть. Сейчас в Банке обслуживается около 100 000 частных лиц и свыше 15 000 корпоративных клиентов и клиентов малого и среднего бизнеса. Старт системы SAP ERP запланирован на март 2010 года. Взято отсюда.

Update 28.07.2010 успешное внедрение SAP ERP. Информация здесь.
“Уникальность данного проекта в том, что в короткое время за 9 месяцев была построена параллельная главная книга в системе SAP по отношению к АБС банка со своей детализацией, реализованы задачи функционала SAP ERP HCM, выстроена система управленческого учета с расчетом себестоимости и прибыльности банка по бизнес направлениям и продуктам банка, построена система контроля за бюджетами банка, реализованы задачи бухгалтерского и налогового учета, осуществлена интеграция системы SAP с АБС банка…”

ЗАО «Абсолют-банк» absolutbank.ru

Приобрел решение SAP для формирования управленческой и IFRS отчетности на платформе хранилища данных SAP BW и специализированных компонентов линейки SAP for Banking. В сети есть следы поиска специалистов по SAP BW в банк.

КБ “Ренессанс Капитал” rencap.com

Проекты:
Обслуживание эксплуатации продуктов SAP HCM, включают в себя выполнение поступающих от Заказчика плановых и срочных заявок, в соответствии с которыми компания ЭВОЛА исправляет ошибки в системе SAP, а ОАО КБ “Ренессанс Капитал”  получает более исправно работающую систему. В перечень услуг по обслуживанию эксплуатации ПО SAP HCM в ОАО КБ “Ренессанс Капитал”, оказываемых компанией ЭВОЛА входит также: консультирование сотрудников ОАО КБ “Ренессанс Капитал”  по работе системы, изменение настроек системы, связанных с изменениями в законодательстве, доработка программного обеспечения по запросу Заказчика, тестирование и документирование изменений, произведенных в системе, обновление и разработку инструкций пользователей, проведение технического анализа и подготовка предложения по изменению действующей или вводу новой функциональности Системы. Взято отсюда.

OTP Bank, Украина, Киев    otpbank.com.ua

Внедрена функциональности “Финансы” FI, “Контроллинг” CO, “Инвестиционный менеджмент” IM – как инструмент управления и бюджетирования инвестиций банка, “Управление материальными потоками/склад” MM, “Управление персоналом” HR, “Управление взаимоотношениями с поставщиками” SRM.  Проект был внедрен за рекордные пол-года с мая по декабрь 2007 года. Информация здесь.

 

ОАО БТА-Казань, Казань    bta-kazan.ru

Новость от 10.09.2010. Банк объявил о внедрении функциональности SAP CRM и SAP BCM для работы с клиентами.  В ходе проекта были внедрены следующие функциональности: управление корпоративными продажами; контакт-центр; аналитическая отчетность; управление розничными продажами; управление сбором задолженности; управление маркетингом.

Банк «БТА-Казань» привлек к сотрудничеству одного из ведущих поставщиков программного обеспечения и IT-услуг в Центральной и Восточной Европе – компанию IBS. Между компаниями было подписано соглашение о сопровождении и поддержке SAP-систем.

 

 

ПАО Проминвестбанк, Украина, Киев pib.com.ua

Новость от 30.09.2010. Целью внедрения компонентов SAP ERP HCM является максимальная автоматизация широкого спектра задач кадровых подразделений банка: управление персональными данными сотрудников; управление процессом рекрутинга и формирование кадрового резерва; сопровождение корпоративного обучения персонала; обработка документации; управление затратами на персонал, портальные сервисы: самообслуживание сотрудников и менеджеров, электронное обучение, развитие и набор персонала, визуализация данных и построение аналитической отчетности с помощью решений SAP BusinessObjects.  Информация здесь.

Информация от 16.04.2014 «Проминвестбанк» усовершенствовал управление персоналом внедрив SAP ERP HCM

Кредит-Днепр Банк, Украина, Днепропетровск creditdnepr.com.ua

Новость от 10.09.2010. Заявлено о проекте в рамках которого будет построена система аналитической отчетности на базе решения SAP Business Objects. Информация здесь.

Росбанк  www.rosbank.ru

Здесь написано, что есть успешное хранилище.
Здесь, что “АКБ «Росбанк» обеспечил углубленный анализ по более 20 000 000 открытых счетов более 5 000 000 клиентов банка благодаря применению решений SAP.”

Бинбанк  binbank.ru

Отсюда:   Внедряется система управления персоналом в Бинбанке.

update 03.08.2012  Бинбанк внедрил SAP ERP HCM

Юниаструм Банк   uniastrum.ru

28.02.2012 искали на рынке начальника отдела аналитики со знанием SAP BusinessObjects и с навыками оптимизация архитектуры  хранилища данных.

 

UniCredit Bank (ПАО “Укрсоцбанк”) unicredit.com.ua

Компания «Софт-Рейтинг Консалт» сообщает о продуктивном старте системы SAP ERP в UniCredit Bank (ПАО “Укрсоцбанк”, Украина) – 28.11.2011

Помнится, Укрсоц долго и мучительно внедрял Тименос. Ждем, может до SFB когда-нибудь дорастут)

 

DemirBank, Азербайджан azerdemiryolbank.com

Внедрение полного пакета системы “SAP for Banking”, который включает такие модули как “SAP CRM for Banking”, “SAP ERP”, “SAP Deposit Management”, “SAP Loan Management”, “SEM for Banking”, “SAP FSCM / Treasure and Risk Management” позволят в дальнейшем DemirBank-у перейти на более качественный уровень деятельности. “SAP for Banking” в таком объеме впервые в Азербайджане и на Южном Кавказе внедряется в DemirBank. Информация здесь.

С внедрением программы “SAP for Banking” рыночная стоимость азербайджанского DemirBank увеличится минимум на 20 миллионов манатов. Информация здесь.

В январе 2013 года выпущен пресс-релиз об успешном внедрении ряда модулей программного обеспечения SAP for Banking

Проект по локализации SAP for Banking под российское законодательство.
Иттерации по проекту начались в 2005 году, когда компания ОТР сообщила про разработку требований на локализацию SAP for Banking.

В 2007 г. об успешной реализации решения отчиталась компания ND-Group (пресс-релиз здесь), а затем компания ОТР (пресс-релиз здесь). Сейчас созданные решения не поставляются SAP.

Проект по локализации SAP for Banking под российское законодательство – 2

Компания SAP CIS в 11.2011-01.2012 собирала специалистов с рынка для нового проекта локализации. Ждем новостей.


Три основных недостатка современных хранилищ данных

Четверг, Декабрь 24th, 2009

Вон Ким

В последние несколько лет многие предприятия создают хранилища (и киоски) данных, чтобы выполнять над ними приложения. Используемые технологии хранилищ данных опираются, прежде всего, на средства ETL (extract-transform-load – <<извлечение-преобразование-загрузка>>), моделирование и проектирование баз данных, а также на системы реляционных баз данных. Сегодняшним хранилищам данных присущи три основных недостатка. Это неудовлетворительная обработка <<грязных>> данных, неудовлетворительные производительность и масштабируемость при выполнении операций, основанных на сканировании, а также неудовлетворительный выбор источников данных для загрузки в хранилище данных. В статье анализируются эти три проблемные области и приводятся основные черты подходов к решению проблем.

Во второй половине 90-х во многих предприятиях стали осознавать, что имеющиеся в их распоряжении данные являются ценным достоянием, правильное использование которого может создать конкурентные преимущества. Однако они понимали, что их данные хранятся в разрозненных системах, и для выполнения приложений данные необходимо интегрировать. Потребность в интеграции корпоративных данных послужила толчком к созданию хранилищ данных (а также киосков данных, эквивалента хранилища данных на уровне подразделения компании). Многие предприятия вложили значительные средства в создание хранилищ и киосков данных, чтобы запускать над ними новые приложения и даже модернизировать свои бизнес-процессы.

Для создания хранилища данных предприятию в общем случае нужно выполнить следующие шаги:

1. Проанализировать имеющиеся данные во всех источниках данных с целью инвентаризации семантики и контента.
2. Спроектировать хранилище данных (схему базы данных) с учетом данных, доступных во всех имеющихся источниках, и данных, которые требуются для приложений (т.е. запросов, которые будут генерироваться приложениями).
3. Извлечь нужные данные, преобразовать извлеченные данные в соответствии проектом хранилища данных и загрузить преобразованные данные в хранилище.

Для хранения информации и управления хранилищами и киосками данных, как правило, используются системы реляционных баз данных (РБД). После создания стабильного хранилища его необходимо регулярно обновлять, чтобы отражать в нем обновления данных в источниках.

После создания хранилища данных предприятие может выполнять над ним одно или несколько приложений. В число приложений обычно входят средства поддержки запросов для генерации отчетов, приложения для управления связями с заказчиками (например, отслеживание маркетинговых кампаний, сегментация заказчиков и анализ поведения заказчиков при совершении покупки и т.д.), анализаторы данных, содержащихся в Web-журналах, приложения добычи данных (например, средства выявления попыток мошенничества), бизнес-аналитика (например, анализ рентабельности) и т.д. Приложения генерируют SQL-запросы, которые передаются системе РБД, управляющей хранилищем данных.

Несмотря на довольно большое количество уже созданных хранилищ и киосков данных и довольно большое число выполняемых приложений, на сегодняшний день имеются, по крайней мере, три существенные проблемы, связанные с хранилищами данных. Они состоят в управлении грязными данными, оптимальном выборе источника данных, а также в производительности и масштабируемости операций, основанных на сканировании. Недостаточное внимание уделялось качеству (корректности) данных и влиянию грязных данных на результаты запросов, добычу данных и анализ. Недостаточное внимание уделялось и проблеме загрузки в хранилище данных тех и только тех данных, которые требуются для ответов на запросы, генерируемые приложениями. Системы РБД хорошо проявляют себя при выполнении запросов, предполагающих выборку малой части записей из большой базы данных, но полностью зависят от скорости ввода-вывода при выполнении запросов, для которых требуется чтение с диска или запись на диск таблицы (или файла)целиком. Исследуем все эти проблемы и обсудим некоторые подходы к их решению.

Проблемы качества данных

С последствиями грязных данных мы сталкиваемся в своей повседневной жизни. Мы получаем массу почтовых отправлений с орфографическими ошибками в именах, множество посланий с разными вариантами одного и того же имени, массу писем, адресованных людям, которые давно переехали, банковские уведомления о многочисленных расходных операциях (в то время как деньги со счета снимались лишь однажды) и т.д. К грязным данным относятся отсутствующие, неточные или бесполезные данные с точки зрения практического применения (например, представленные в неверном формате, не соответствующем стандарту). Грязные данные могут появиться по разным причинам, таким как ошибка при вводе данных, использование иных форматов представления или единиц измерения, несоответствие стандартам, отсутствие своевременного обновления, неудачное обновление всех копий данных, неудачное удаление записей-дубликатов и т.д.

Очевидно, что результаты запросов, добычи данных или бизнес-анализа над хранилищем, содержащим большое число грязных данных, не могут считаться надежными и полезными. Только сейчас предприятия начинают внедрять инструменты очистки данных. Представленные сегодня на рынке средства очистки данных (например, продукты компаний Vality/Ascential Software, Trillium Software и First Logic) помогают выявлять и автоматически корректировать некоторые наиболее важные типы данных, в особенности, имена и адреса людей (с использованием национального каталога имен и адресов). Однако этим средствам предстоит пройти еще долгий путь, поскольку сегодня они не умеют работать со всеми типами грязных данных, и далеко не все компании используют даже имеющиеся средства. Более того, большинство предприятий не внедряет надежные методики и процессы, гарантирующие высокое качество данных в хранилище. Недостаточное внимание, уделяемое качеству данных, обусловлено отсутствием понимания типов и объема грязных данных, проникающих в хранилища; влияния грязных данных, принятие решений и выполняемые действия; а также тем фактом, что продукты очистки данных, представленные на рынке, не слишком хорошо рекламируются или слишком дорого стоят.

Для того чтобы начать уделять необходимое внимание качеству данных в своих хранилищах, предприятиям, прежде всего, нужно разобраться в многообразии возможных грязных данных, источниках их появления и методах их обнаружения и очистки. Разумной стартовой точкой может служить [1]. В этой статье представлена по существу исчерпывающая таксономия 33 типов грязных данных и также разработана таксономия методов предотвращения или распознавания и очистки. Таксономия грязных данных демонстрирует многие типы грязных данных, с которыми не справляются сегодняшние средства очистки. В ней также указываются различные типы грязных данных, которые могут быть автоматически обнаружены и очищены, или даже появление которых может быть предотвращено. Однако, к сожалению, в статье демонстрируется большое число видов грязных данных, которые непригодны для автоматического обнаружения и очистки, и появление которых невозможно предотвратить. Например, по ошибке в базу данных вводятся данные о том, что возраст некоторого человека составляет 26 лет, в то время как в действительности ему 25 лет; или вводится имя человека Larry Salcow, а на самом деле оно пишется как Larry Salchow; или же адреса <> и <> являются старым и новым адресами одного и того же человека. Эти грязные данные появляются по причинам ошибки при вводе данных, неудачным обновлением адреса человека или неудачной стандартизации представления имени. Понятно, что никакое программное средство (и даже человек) не смогут обнаружить, что эти данные являются грязными. Конечно, теоретически можно произвести дорогостоящую перекрестную проверку данных из разных источников (файлов или таблиц), которые содержат информацию о возрасте, имени и адресе одного и того же человека.

Далее, предприятиям требуется оценить стоимость наличия грязных данных; другими словами, наличие грязных данных может действительно привести к финансовым потерям и юридической ответственности, если их присутствие не предотвращается, или они не обнаруживаются и не очищаются. Предположим, что компания осуществляет рассылку рекламных материалов на 100 тыс. адресов по цене 2 долл. за адрес. Если 2% адресов являются грязными, доставить по ним материалы не удастся. Две тыс. почтовых отправлений обойдутся в 4 тыс. долл. (Для простоты проигнорируем тот факт, что на самом деле 98% массовых почтовых отправлений, даже доставленных должным образом, все равно останутся без ответа.)

Тот факт, что наличие грязных данных влечет расходы, не обязательно означет необходимость предотвращения грязных данных или их распознавания и очистки. Дело в том, что должна оцениваться также и стоимость предотвращения или распознавания и очистки грязных данных. Если требуется двухчасовое выполнение процедуры очистки данных для коррекции адресов из нашего примера, и компания уже расплагает средством очистки данных, то имеет смысл потратить время на исправление адресов перед началом рассылки. Однако будет лучше ничего не делать с неверными адресами, если можно нанять на 100 дней и за 10000 тыс. долл. человека, который вручную проверит правильность всех адресов, руководствуясь телефонным справочником или базой данных регистрации транспортных средств.

Проанализируем стоимость предотвращения, обнаружения и очистки грязных данных. Появление грязных данных любого типа можно предотвратить или распознать и очистить (автоматически или вручную), но это влечет расходы. В общем случае для каждого типа грязных данных имеется несколько, отличающихся по цене, способов предотвращения или обнаружения и очистки недействительных данных. К примеру, средства управления транзакциями в системах РБД предотвращают появление некоторых типов грязных данных, обуславливаемых потерянными обновлениями, а также грязным и неповторяемым чтением [1]. Определение ограничений целостности, таких как типы данных, ограничения уникальности, запрета наличия неопределенных значений и внешних ключей заставляет систему РБД автоматически поддерживать целостность данных при выполнении операций вставки, обновления и удаления. Эти средства являются частью системы РБД, и их выполнение занимает относительно небольшую часть машинного времени. Для выявления неправильно написанных слов имеет смысл запустить процедуру проверки орфографии. Для исправления неверно написанных имен и адресов можно использовать справочник, из которого можно почерпнуть и дополнительную информацию, в частности, почтовый индекс, название административного округа и т.д. Для принятия рекомендаций программных средств обычно требуется вмешательство человека. Можно обеспечить в значительной степени автоматическое обнаружение грязных данных некоторых типов, но гарантировать абсолютную корректность можно не всегда. Например, можно использовать средство автоматической проверки вхождения числового значения в указанный диапазон, для гарантии того, что возраст человека находится в диапазоне от 18 до 67 лет. Чтобы гарантировать отсутствие ошибок ввода, можно поручить нескольким людям проверку и перепроверку вводимых данных.

Стоимость исправления грязных данных зависит также от общего объема данных и пропорции грязных. Очевидно, что для проверки файла с большим числом записей и полей потребуются более серьезные усилия, чем для файла с меньшим числом записей и полей. Стоимость обнаружения и исправления одного элемента грязных данных в единственном поле единственной записи зависит от типа грязных данных.

Несомненно, что большинство предприятий сегодня не предпринимает достаточных усилий для обеспечения высокого качества данных в своих хранилищах. Для обеспечения высокого качества данным предприятиям нужно иметь процесс, методологии и ресурсы для отслеживания и анализа качества данных, методологию для предотвращения или обнаружения и очистки грязных данных и методологии для оценки стоимости грязных данных и затрат на обеспечение высокого качества данных. В Ewha Women’s University разработан прототип инструментального средства DAQUM (Data Quality Measurement), предназначенного для отслеживания большинства типов грязных данных и приписывания разным типам грязных данных количественной меры качества данных в зависимости от особенностей приложений [2]. В этом направлении нужно предпринимать дополнительные усилия.

Проблемы выбора источников данных

Сегодня проектировщики хранилищ данных проектируют схему базы данных целевого хранилища данных с использованием средств моделирования баз данных. Схема базы данных состоит из таблиц, столбцов (полей) таблиц, типов данных и ограничений столбцов, а также связей между таблицами. Проектировщики также определяют отображения (преобразования) схем источников информации на схему целевого хранилища данных.

Но как проективщики могут убедиться в том, что хранилище данных содержит все данные, нужные приложениям, которые будут над ним выполняться, и не содержит никаких данных, которые приложениям не нужны? Сегодня это основывается на основе догадок опытных проектировщиков. Проектировщикам приходится выявлять потребности в данных (таблицы и столбцы), опрашивая разработчиков приложений, бизнес-аналитиков (людей, которые понимают потребности приложений и бизнеса) и администраторов баз данных. После начального создания хранилища часто оказывается, что в нем отсутствуют данные, требуемые для получения ответов на некоторые запросы, и присутствуют данные, которые никогда не требуются приложениям. Хотя стоимость хранения может быть относительно небольшой, все поля, нужные и ненужные, хранятся в одних и тех же записях и считываются и записываются совместно, что замедляет скорость выборки, увеличивает время обработки, а также приводит к неэффективному использованию среды хранения.

В исследовательской литературе описано много предложений по моделированию хранилища данных в виде репозитария результатов всех выполняемых запросов [4-6]. Авторы этих предложений пытаются найти алгоритмы, которые будут выбирать(для загрузки в хранилище данных) подмножество исходных данных, минимизирующее общее время ответов на запросы. Некоторые из авторов пытаются также минимизировать стоимость обновления хранилища данных. Другими словами, они основываются на предположении, что все запросы к хранилищу данных можно заранее узнать или предсказать и что можно заранее узнать или предсказать все возможные изменения хранилища данных, а следовательно, и исходных источников данных.

Идеальный способ выборки данных для загрузки в хранилище данных состоит в том, что прежде всего определяются все запросы, которые будут генерироваться всеми приложениями, выполняемыми над хранилищем данных, и определяются таблицы и поля, фигурирующие в этих запросах. Определение всех запросов до создания хранилища данных является трудной задачей. Однако это может стать возможным после начального создания хранилища данных за счет регистрации в течение разумного промежутка времени всех запросов, поступающих от приложений. Анализ зарегистрированных запросов может быть использован для тонкой настройки хранилища данных и удаления данных, к которым приложения не осуществляют доступ.

Потенциально полезным и практичным является средство, которое анализирует потребности приложений в данных, автоматически сопоставляет эти потребности со схемами источников данных и выдает рекомендации по составу оптимального поднабора источников данных, которые нужно загрузить в хранилище данных, чтобы в нем находились все нужные данные и не находились какие-либо ненужные. Таким средством является MaxCentra, коммерческая версия которого была выпущена совсем недавно [3]. Функционирование MaxCentra опирается на наличие предварительно построенной базы знаний ключевых слов, которая представляет потребности приложений в данных. Ключевые слова в основном представляют собой неявные указания таблиц и полей, к которым будет осуществляться доступ при выполнении запросов, генерируемых приложением. Такой список ключевых слов может быть обеспечен бизнес-аналитиками или разработчиками приложений, или же он может быть получен автоматически путем анализа запросов от приложений, выполняемых над неоптимизированным хранилищем данных. MaxCentra отталкивается именно от этого и при поддержке и содействии проектировщиков позволяет получить оптимальную схему базы данных для хранилища данных. Работа MaxCentra включает несколько вычислительных этапов, и проектировщик хранилища данных может подтвердить или скорректировать результаты выполнения каждого этапа. Если выполнение MaxCentra основывается только на ключевых словах без учета зарегистрированных запросов, то программа производит стандартную обработку ключевых слов (морфологический анализ, разбиение составных слов, выявление одинаковых слов и т.д.). Затем производится упорядочение таблиц и полей в источниках данных с учетом их релевантности потребностям приложений в данных, группируются таблицы и поля, которые являются избыточными или могут быть порождены одно другим (так что избыточные или несущетственные таблицы и поля могут быть удалены), и группы упорядочиваются с учетом их релевантности потребностям приложений в данных.

Проблемы производительности и масштабируемости

В системах РБД для выборки небольшого количества нужных записей без полного сканирования таблицы или базы данных используются различные методы доступа, такие как индексы на основе хеширования или B+-деревьев. Такие методы доступа весьма эффективны при выборке по одному ключевому полю (или небольшому числу полей), когда результаты представляют собой малую часть таблицы. Примерами подобных запросов являются: <<найти всех 25-летних людей>>, <<найти всех инженеров-программистов>> или <<найти всех 25-летних инженеров-программистов>>. Для быстрого ответа на такие запросы можно создать индексы: на столбце <<Возраст>> таблицы <<Сотрудники>>, на столбце <<Занимаемая должность>> таблицы <<Сотрудники>> и на столбцах <<Возраст>> и <<Занимаемая должность>> таблицы <<Сотрудники>> соответственно.

Однако методы доступа в общем случае не помогают при ответе на запросы, результатами которых является значительная часть таблицы. Примерами являются запросы: <<найти всех сотрудников женского пола>>, <<найти всех некурящих сотрудников>> и <<найти молодых сотрудников>>. Кроме того, методы доступа не приносят пользы, если значения столбца часто изменяются, поскольку такие изменения требуют перестройки методов доступа. Это примеры <<простых>> запросов, для выполнения которых методы доступа в системах РБД оказываются бесполезными.

Помимо подобных <<простых>> запросов существуют два класса операций, для которых методы доступа в системах РБД становятся бессильными. К первому классу относятся операции <<агрегации>>, предусматривающие группировку всех записей таблицы и применение к сгруппированным записям агрегатных функций (среднего значения, общего числа, суммы, минимального или максимального значения). Этот тип операций важен в таких приложениях как анализ данных Web-журналов, сегментации данных о заказчиках и т.д. Различные методы, связанные с проблемой эффективности операций этого класса, анализируются в [7], включая сжатие данных, метод хранения таблицы по полям (хранение каждого поля таблицы как отдельного файла), предварительные вычисления (гиперкубов OLAP, сводных таблиц) на основе детализированных данных, нормализацию (разбиение таблицы на несколько более мелких таблиц) и параллельную обработку. На рынке имеются продукты MaxScan и Ab Initio, предназначенные для решения проблем производительности и масштабируемости при выполнении данного типа операций. В MaxScan применяется метод хранения таблиц по полям, методы хеширования для группировки и агрегирования записей, а также методы параллельной обработки. Производительность и масштабируемость при выполнении агрегатных операций в 10-20 раз превышают показатели систем РБД. Ab Initio является средством ETL, в котором в механизме трансформации данных используются методы повышения производительности.

К другому классу относится операции <<перемещения файлов>>, читающие и/или записывающие файл(ы) целиком. Этот тип операций важен на этапе требующем больших временных затрат <<преобразования данных>> при создании хранилища данных или на этапе <<подготовки данных>> при автоматическом извлечении знаний (добыче данных) из имеющихся источников [8]. Этап преобразования данных включает трансформацию формата и представления данных в заданных полях (изменение единицы измерения, изменение формата даты и времени, изменение аббревиатуры и т.д.), слияние двух или более полей в одно, расщепление поля на два или более полей, сортировку таблицы, построение обобщенной таблицы из таблиц, содержащих детализированные данные, создание новой таблицы путем соединения двух или более таблиц, слияние двух или более таблиц в одну, расщепление таблицы на две или более и т.д. К этапу подготовки данных относятся преобразование данных заданного поля в цифровой код (в нейронных сетях), преобразование непрерывных цифровых данных в заданном поле в категорические данные (например, возраст, превышающий 60 лет, считается <<пожилым>>), добавление к записи нового поля, взятие из таблицы образцов данных, репликация в таблице некоторых записей (для достижения желаемого распределения записей) и т.д. Более подробное обсуждение этих операций приводится в [9].

Сегодня операции перемещения файлов находятся в почти полной зависимости от последовательных операций систем РБД над файлами, т.е. чтения одного или более файлов, создания временного файла и записи результирующего файла или файлов. Частота выполнения подобных операций и объем используемых данных может сделать оправданным применение сервера преобразования/подготовки данных. В идеале такой сервер может состоять из нескольких параллельно работающих процессоров. Независимо от конфигурации процессора на нем должны выполняться программные средства преобразования/подготовки данных, спроектированные для параллельной обработки. Когда это оправданно, нужно применять конвейерную параллельную обработку, при которой получение частичных результатов одной операции инициируют выполнение другой операции без потребности ожидания завершения первой операции. Конвейерная параллельная обработка устраняет потребность в записи во временный файл полных результатов одной операции и в их чтении следующей операцией, что позволяет сэкономить два ввода-вывода файла. Для создания сводных таблиц вместо <<родных>> функций системы РБД имеет смысл использовать механизм быстрой сортировки, такой как SyncSort, или механизм быстрого агрегирования, такой как MaxScan. Кроме того, для выполнения вычислений <<запись за записью>> (выборка образцов, преобразование формата или представления данных и т.д.) имеет смысл разбить файл на несколько подфайлов и назначить каждому из них отдельный процессор для обеспечения параллельной обработки.

Заключение

В этой статье мы выделили три основных проблемы, которым уделяется недостаточное внимание при создании хранилищ данных: качество данных, оптимальный выбор источников данных и производительность и масштабируемость. На рынке имеется несколько средств очистки данных, которые начинают применяться для очистки грязных данных разнообразных типов. Однако эти средства, конечно, не затрагивают все типы грязных данных, и, конечно, лишь немногие предприятия принимают на вооружение такие средства или процессы для предотвращения или обнаружения и очистки грязных данных, а также для отслеживания и проведения количественной оценки качества данных в хранилищах данных. Сегодня в хранилищах данных содержится множество данных, которые никогда не используются приложениями, выполняемыми над этими хранилищами данных, и эти ненужные данные являются одной из причин снижения эффективности выполнения запросов. Нужно обеспечить возможность регистрации полного набора запросов, генерируемых всеми приложениями, и использования таблиц и полей, фигурирующих в запросах, для тонкой настройки содержимого хранилищ данных. В сегодняшних хранилищах данных для хранения данных и управления ими в значительной степени используются системы РБД. Однако возможности сегодняшних систем РБД не достаточны для обработки запросов, ориентированных на сканирование, таких как группировка записей и вычисление агрегатов, и операций перемещения файлов, которые преобладают на этапе преобразования данных хранилищ данных и этапе подготовки данных при добыче данных.

Литература

1. W. Kim, B. Choi, E. Hong, S. Kim, D. Lee. “A Taxonomy of Dirty Data”, Journal of Data Mining and Knowledge Discovery, the Kluwer Academic-Publishers, 2003.
2. W. Kim, et al. “The Chamois Component-Based Knowledge Engineering Framework”, IEEE Computer, 2002, May, IEEE CS Press.
3. W. Kim, E. Hong, K. Kim, D. Lee. “A Component-Based Architecture for Preparing Data in Data Warehousing”, Journal of Object-Oriented Programming, 2000 March/April.
4. H. Gupta. Selection of Views to Materialize in a Data Warehouse. In Proceedings of the Intl. Conf. on Database Theory, 1997 January.
5. J. Yang, K. Karlapalem, and Q. Li. Algorithms for Materialized View Design in Data Warehousing Environment. In Proc. of the 23th VLDB Conference, 1997 August.
6. Yannis Kotidis and Nick Roussopoulos. DynaMat: A Dynamic View Management System for Data Warehouses. In Proc. of ACM SIGMOD Conference, 1999 June.
7. W. Kim. “Business Intelligence at Top Speed”, Intelligent Enterprise, Miller Freeman, Inc., 1998, Dec. 15.
8. D. Pyle. Data Preparation for Data Mining, Morgan Kaufmann Publishers, 1999.
9. W. Kim. “I/O Problems in Preparing Data for Data Warehousing and Data Mining – Part 1″, Journal of Object-Oriented Programming, 101 Communications, 1999. Feb.

Рынок ERP (почему ERP проект стоит дорого)

Среда, Декабрь 2nd, 2009

Статья опубликована в еженедельнике “Компьютерра” № 10 от 10.03.2009

Москва 2009г. Мартынов Дмитрий

статья ” Рынок ERP (почему ERP проект стоит дорого) “

Кризис заставляет многие компании выбирать, за что они готовы платить. Означает ли это, что поставщики ERP-систем снизят цены, чтобы сохранить спрос? И вообще, если взять шире, высокие цены на ERP это реальность, или миф, придуманный интеграторами и производителями софта?

Цены определяются рынком, который в нашей стране сформировался недавно. Становление российского капитализма пришлось на рассвет мировой компьютерной автоматизации.

В те времена программы для компаний делали одиночки-любители, используя для этого системы типа Clipper, FoxPro, которые работали в системе MS DOS. Я, конечно, упрощаю. Использовалось еще множество других программ, но ERP не было. Каждый писал свою «ERP-систему» сам. Термин «ERP-система» в данном случае следует понимать иносказательно. В большинстве случаев эти системы не дотягивали по функциональности до современных систем. Однако сейчас, в большинстве проектов используется 15-20% функционала ERP так, что по объему действующих функций системы тогда и сейчас вполне сопоставимы.

Хорошие компьютеры в те времена стоили дорого, их привозили из США и Европы поштучно или небольшими партиями. Хорошие программисты стоили дешево. Дико звучали вести с запада, о том, что там стоимость программистов больше стоимости железа.

Постепенно наша страна втянулась в мировой рынок, и цены у нас стали больше соответствовать западным. В настоящий момент почти в любом ERP-проекте стоимость железа на порядок меньше стоимости работы консультантов, программистов и системных администраторов (специалистов по сетям и железу).

Железо и софт трудно сравнить по себестоимости (мы сделаем это позже), разница является следствием мировой тенденции. К этому можно приспособиться или извлечь из этого свою выгоду. Правда, для тех, кто привык к дешевым качественным программистам, такое изменение структуры цен оказалось шоком.

Я не хочу оперировать конкретными цифрами. Важны причины происходящего, а цифры все время меняются – инфляция. Рядовой квалифицированный специалист по ERP на «неайтишном» предприятии получает зарплату, сравнимую с зарплатой начальника отдела (если, конечно, это не начальник отдела продаж). Значит, такова его значимость для предприятия. Но имеет смысл изучить факторы, которые могут толкать цену на ERP проекты вниз и вверх.

ERP – это просто и должно стоить дешево

“Два солдата из стройбата заменяют экскаватор”

Детская считалка

Стоимость ERP системы можно разделить на несколько составляющих:

  1. Железо. Серверы, компьютеры и другие периферийные устройства, а также сетевое оборудование.
  2. Программное обеспечение.
  3. Работа специалистов:
    • Работа по администрированию программного обеспечения: его установка и предварительная настройка;
    • Работа консультантов по организации проекта – это инженерная работа;
    • Работа консультантов по настройке системы в соответствии с бизнес-процессами;
    • Обучение пользователей, написание пользовательской документации (тоже делают консультанты);
    • Работа программистов – написание дополнительных модулей, доделка функциональности.

В третьем пункте пугающий список специалистов. И ведь все эти админы, программисты и консультанты хотят хорошо питаться и покупать дорогие машины. А как же раньше всю эту структуру заменял один специалист?

В одном пресс релизе было написано: для мотивации начальника отдела продаж, была разработана формула на основе тригонометрических функций. Кто то сказал: они приступили к капитализации знаний средней школы. Да уж, при внедрении ERP систем даже до такой математики руки не доходят, все сводится к арифметике. Впрочем, есть еще структуры данных (это часть теории множеств – уже высшая математика). Но в большинстве ERP-систем структуры данных спроектированы на коленке (без применения сложных мат.инструментов). Впоследствии, это вызывает проблемы быстродействия и нарушение целостности данных, но чаще всего эти проблемы не сильно мешают работе. Про них неожиданно (к сожалению чаще уже с опозданием) вспоминают только на проектах для крупных компаний с большим количество операций и рабочими местами разнесенными на большие расстояния.

Люди из науки при столкновении с ERP приходят в недоумение. Ничего сложного в ERP нет. Почему же она стоит так дорого?

ERP нужна всем

Потому что цену определяет спрос. Эффективность ERP позволяет получить конкурентные преимущества. А предприятий много, и каждому нужна система. Спрос должен определить и предложение, но интеграторов и их ресурсов по развертыванию ERP не хватает, чтобы обслужить всех заинтересованных. Вот и цены на услуги выше ожиданий многих желающих.

Сразу возникает сравнение с искусственно надутым пузырем. Да, на таком ненасыщенном рынке можно играть на повышение. Например, многие производители ERP систем умело используют психологию заказчиков, которые уверены, что хорошие вещи стоят дорого. Создав правильный ореол вокруг своей продукции, сделав его похожим на результат научной разработки, поставить цену существенно выше аналогов и заявить, что это связано с качеством ПО – это типичный трюк.

Но если это такой простой и такой прибыльный бизнес, почему компаний-интеграторов меньше, чем нужно? Что мешает хоть завтра открыть свою компанию, которая будет заниматься системной интеграцией, или разработать свою ERP-систему? Мешают несколько «но».

Тотализатор и качество коробок с ERP

Эффект тотализатора проявляет себя во многих сферах человеческой жизни и рынку ERP он тоже не чужд. Клиент купит систему, о которой уже слышал. А больше информации там, где больше продаж.

Но эффект усугубляется особенностью технологии. Выбор распространенной ERP является правильным с точки зрения оптимизации затрат на сопровождение. Представим, что вы выбрали редкую, но дешевую ERP систему, и однажды вам понадобилось добавить еще одну функцию. Вы обратились к производителю, и он назвал цену. Вы не можете ни проверить эту цену, ни уменьшить ее. На рынке нет ни фирм, ни специалистов, которые могли бы решить вашу задачу. Особенный продукт – особая цена…

Значит, выбираем распространенную систему, а после выберем интегратора, который будет ее внедрять и сопровождать. В результате ERP попавшие в TOP 10 имеют возможность держать высокие цены на лицензии своих систем. Интересно, что это мало связано с их качеством. Дело в том, что не существует осмысленных методик сравнения ERP систем (об этом я писал в статье «Проблемы быстродействия ERP – системный кризис»). Получается, что увеличением количества разных ERP-систем на рынке цену опустить нельзя.

Затраты интеграторов

Новых интеграторов на рынке появляется мало и я уверен, что ситуация ближайшее время не изменится. У них есть особые затраты, связанные с особыми рисками бизнеса, которые влияют на себестоимость услуг. Что это за затраты?

Поговаривают, что существует большой процент заваленных ERP-проектов. Это правда, но достоверной статистики нет и не будет. Кто ж добровольно напечатает новость о том, что завалил проект. Так как внедрение – это совместное мероприятие заказчика и исполнителя, которое зависит о обоих, то виноват всегда оказывается заказчик (по проектным документам, которые готовит исполнитель), и раздувать скандал никому не выгодно.

В результате существует недоверие предприятий к компаниям, внедряющим ERP. Чтобы сломить это недоверие, интеграторы имеют особые представительские статьи затрат. Существуют затраты на наукообразный дизайн всех составляющий деятельности. Презентации, которые интегратор проводит у потенциальных заказчиков, должны быть сделаны хорошо, их должны делать квалифицированные специалисты. Многие интеграторы имеют в штате специалистов, которые занимаются только подготовкой презентаций, а в проектах непосредственно не участвуют.

Интеграторы сами себя загнали в ловушку. Значительные риски проекта, приводят к нерешительности потенциальных заказчиков. Решение о начале проекта принимается долго. В результате приходится проводить много презентаций, к тому же потенциальный заказчик может и вовсе отказаться от проекта, или обратиться к конкуренту. С точки зрения затрат на качества многие интеграторы ставят презентации выше самих проектов.

Чтобы минимизировать риски и приблизить проект, многие идут на подкуп. Откаты являются существенной статей затрат интегратора.

А разве ERP это просто?

«Нет ни одного открытия ни в технологии, ни в методах управления, одно только использование которого обещало бы в течении ближайшего десятилетия на порядок повысить производительность, надежность, простоту разработки программного обеспечения»

Федерик Брукс. «Мифический человеко-месяц», 1975

Если все просто, но этого всего много, то получается сложно. ERP-система автоматизирует большое количество различных бизнес процессов. Для каждого существует куча настроек, которые влияют на результаты друг друга. Получается невероятное количество возможных сочетаний настроек (например, 100 настроек по 10 вариантов для каждой это получается 10e100 сочетаний – столько же позиций в шахматах ). Зазубрить нельзя, нужно понимание, ведь эти настройки связаны с принятыми стандартами бухгалтерского учета, с особенностями управленческого учета и управления, и эти особенности свои для каждого бизнес-процесса, к тому же в разных фирмах одни и те же организационные и учетные задачи принято решать по разному.

Настройка системы по сложности сравнима с программированием ее с нуля. Чаще всего настройкой дело не ограничивается, и систему дописывают. Добавим к этому особенности системного и сетевого ПО, а также систем управления базами данных, которые тоже влияют на качество корпоративной системы. Эти настройки часто взаимосвязаны с настройками ERP. А все производители софта, постоянно выпускают новые версии, в которых прежние функции часто работают иначе. К тому же весь этот софт содержит большое количество багов и недокументированных функций, которые тоже надо или иметь в виду сразу при подготовке проекта, или с этим придется разбираться на этапе тестирования (а еще хуже если при внедрении), когда обнаружиться что чтото работает не так как было задумано.

Брукс не ошибся. То, что он сказал тридцать лет назад, верно до сих пор. И думаю, что ситуация не изменится еще долго. ERP система – сложный инженерный проект, и им должен управлять инженер, имеющий минимально необходимые знания во всех указанных областях, а также и в бизнесе, который он пытается автоматизировать. Встречаются специалисты, которые могут все: и жрец, и на дуде игрец. Именно на них держалась автоматизация в девяностых. Именно они обеспечивают эффективность внедрения сейчас. Но таких универсалов мало. Очень мало.

Итог: сколько будет успешных проектов?

- Из этой шкуры шапку сшить
Ты можешь или нет?
– Могу! – сказал в ответ скорняк,
На шкуру посмотрев.
– А выйдет две? – спросил Вартан,
На корточки присев.

Сергей Михалков

Откройте хоть сто тысяч фирм по системной интеграции, если есть 500 экспертов, то будет 500 проектов, а больше не будет. Точнее будет и больше, но успешных только 500. Получается, что специалисты – это козырная карта. Я всегда рекомендую выбирать интегратора по резюме его специалистов.

Теперь, проанализировав все значимые факторы, попробуем предсказать будущее рынка ERP систем:

  1. Цены на железо? с ними проблем не ожидается. Железо выпускается серийно и продается по фиксированным ценам. На рынке железа довольно сильная конкуренция, а значит, цена может даже снижаться. Впрочем, на цену техники всегда оказывают влияния общие факторы: значимость бренда, стоимость нефти, стоимость рабочей силы и даже стоимость пресной воды, но принципиального изменения стоимости этих компонентов пока не ожидается.
  2. Цены на лицензии за ERP? наименее предсказуемые. Цена будет меняться в зависимости от военных действий между производителями ERP из списка ТОП 10. Однако я уверен, что цена существенно не снизится: десять фирм – это олигополия, со всеми вытекающими последствиями. А ТОП 3 ? вообще фактически монополия.
  3. Работа специалистов? цены будут только расти. В нашей стране ближайшее время количество высококлассных специалистов по внедрению ERP не увеличится. В вузах отсутствует соответствующая специальность. Интеграторы тоже не занимаются подготовкой таких спецов, а только перекупают их друг у друга. Все такие эксперты, к сожалению, самоучки.

Знать будущее, даже в случае, если оно не такое, как хотелось, лучше, чем не знать. То, что цены будут расти, скомпенсировано тем, что вы об этом знаете. У многих есть ощущение, что цены на ERP давно достигли своего потолка, но анализ показывает, что это не так. Думаю, мы еще услышим о проектах за баснословные суммы.

Впрочем, на рынке могут произойти и другие изменения. Например, может увеличиться количество успешных проектов, за счет того, что изменится значение термина «Успешный ERP-проект». Уже сейчас большинство успешных проектов, на мой взгляд, являются позором, а не успехом (т.е. эффект от внедрения, покрывает расходы, но могло быть гораздо круче). Но общепринятых критериев качества нет. Надеюсь, что они скоро появятся, точнее я буду активно над этим работать.

ERP и бред: Как на рынке ERP отличить антинаучный бред от научного бреда

Вторник, Декабрь 1st, 2009

Статья опубликована в еженедельнике “Компьютерра” № 33 от 07.09.2009

Москва 2009г. Мартынов Дмитрий

статья “ERP и бред”

“С точки зрения логической деградации мы не можем отрицать тенденции парадоксальных иллюзий”

Студенческий фольклор

Больше 10 лет я занимаюсь автоматизацией учета и управления, и ни где не обнаружил заметных научных продвижений по этому направлению. Т.е. научная работа ведется, по заявлениям ряда экспертов. Но полезного результата нет. Это напоминает историю про Аральское озеро, уровень воды в котором точнее всех научных моделей предсказывает предположение, что он не измениться на следующий год. Вот и возникает вопрос, а может быть науки и нет, может быть это только видимость, которая сфабрикована под потребности рынка.

Потребность в ERP-науке велика, не зря же весь маркетинг строится на принципах научного дизайна информационных систем и научного дизайна процесса внедрения. Термин “научный дизайн” мы с коллегами ввели, пытаясь классифицировать происходящее. А происходит следующее: то, что печатается напоминает ярмарочную площадь. Эфир заполнен пресс-релизами, через которые каждый норовит кричать в твое ухо про свой, самый ненужный товар. Каждый год тысячи компаний вводят в эксплуатацию миллионы новых программных технологий. Впрочем, чаще всего речь идет о некоторых локальных усовершенствованиях старых систем. Любой опытный программист такое усовершенствование пишет на коленке за одни сутки. В основе большинства новостей рынка лежат именно такие решения, дополненные красочным описанием невероятных возможностей… Такое описание должно создавать эффект научной новизны. В результате каждый год в языке появляется множество новых красивых слов, и тысячи аналитических статей ни о чем.

Похоже, что наука кончилась в 92 году, когда были оставлены без финансирования Российские институты занимающиеся АСУ. Однако проблема наблюдается не только в России. Системного образования по автоматизации учета нет ни где в мире. Например, специальность MBA по IT менеджменту, появилась несколько лет назад, как дань моде и растущему рынку.

Чтобы разобраться в вопросе выделим из помойки терминов автоматизации один ключевой – ERP. Недавно я видел ролик, рекламирующий определенную систему, в нем она сравнивалась с абстрактной ERP системой, разумеется, не в пользу последней. Попытки потопить термин ERP еще долго не будут иметь успеха, т.к. это термин произвел революцию на рынке. Появление ERP (несмотря на расплывчатое определение) привело к метасистемному переходу от автоматизации определенной задачи к автоматизации предприятия. Получилось, что компания, где внедрена ERP и компания где ERP нет – это две большие разницы. На рынке акций стоимость компании при этом меняется в разы.

Но термин термином, а реальность данная нам в ощущениях шепчет, что нужно мерить точнее. Эффективность использования ERP в двух похожих компаниях может иметь колоссальные качественные различия. Это по ощущениям, и по финансовым показателям, но как доказать что на них повлияла именно ERP система? Существует явный недостаток объективных критериев сравнения результатов проектов – даже в похожих компаниях каждый проект имеет кучу своих особенностей, делающих невозможным чистый эксперимент. Найти две или три похожие компании можно, но найти десять уже сложнее. К тому же обычно владельцы компаний, готовые к внедрению инноваций не очень расположены на проведении экспериментов на своей собственности. Владельцы не считают правильным делиться информацией о результатах, считая их своей собственностью. Но эта проблема преодолима, выходят же пресс-релизы об успехах. Непреодолимой проблемой является то, что Интегратор, который озвучит перед клиентом идею провести эксперименты на его объектах, вызывает подозрение граничащее со страхом, ведь широко известна статистика неудачных внедрений (данные различных источников сильно разняться, но даже самые скромные из них говорят о том что не менее 1/5 все проектов заканчиваются неудачей), а раз Интегратор хочет экспериментировать, значит он не знает как надо…

Наука явно не успевает за потребностями рынка. Эффективность систем настолько велика, что рынок готов поглощать эти усовершенствования со скоростью, большей чем это могут обеспечить мощности всех интеграторов. Рынок готов скупать системы разработка которых велась ненаучными методами – лишь бы была эффективность. По тому и цены на услуги взлетели до небес. Здесь многие скептики, ошарашенные кризисом посмеются, и с ними можно согласиться. Активность на рынке, действительно упала, но на это, в частности, влияют те факторы, которым посещена статья. К тому же падение активности почти не сдвинуло цены.

Раз интеграторы обеспечить рынок не могут, а клиенты готовы платить деньги, то желающие получить эти деньги все равно найдутся. Складывается впечатление, что применение крупными компаниями нечестных маркетинговых методов, частично является результатом конкуренции с шарлатанами. Впрочем, все давно уже перемешалось: построение рынка по базарному принципу сделало свое дело. Успешные менеджеры по продажам в среде IT это, чаще всего, проходимцы с высоким коэффициентом проходимости. Сложившаяся на рынке ситуация помогает им, ведь умелое использование логики и демагогии может склонить клиента к нужному решению. Например, в подтверждение этого говорит факт, что для ряда ERP систем, существует градация рабочих мест, и они стоят разные деньги, при этом сами рабочие места функционально не отличаются (т.е. отличается только название рабочего места и его цена). Приведу несколько примеров того как клиента будут с разных сторон окучивать разные лоббисты: (третья колонка – мое частное мнение, его разделяют коллеги нашей команды и многие другие знакомые специалисты и потребители, но все же это, не научная истина…)

1 2 3
Стоит ли вообще что либо внедрять, ведь это дорого, а статистика успешных проектов говорит о том что риски очень высоки. Следует обязательно внедрять новые информационные технологии для снижения человеческого фактора и повышения эффективности бизнес-процессов. Это игра на опережение в конкурентной среде. Эффективность ERP – там где она работает является важной составляющей эффективности всего бизнеса. Но процесс внедрения в мутной воде о которой я писал выше – это большой риск безрезультатных затрат
ERP – это сложно и дорого, а какая будет эффективность и когда окупятся затраты не ясно. А большое количество проектов так и не вводятся в эксплуатацию. Уверен, что мы обойдемся некоторой локальной программой, а анализ сделаем в электронных таблицах. ERP – это очень эффективное решение. Даже если нам нужно локальное решение, завтра нам понадобиться что то еще и в ERP это есть. Нет общепринятых критериев эффективности ERP. Нет и не может быть методик измерения с приемлемой точностью глобальной отдачи от ERP. Все современные методики позволяют делать расчеты в терминах: не окупиться, окупиться, окупиться с лихвой…
Распространенная система это система для всех, а значит не для кого. Надо брать систему соответствующую нашей отрасли там есть нужная функциональность. Важно что эта система уже опробована на ком то, из нашей отрасли, а значит мы тоже сможем добиться нужного результата. Распространенная система лучше, тем что ее легче поддерживать. Существует конкурентный рынок специалистов. А функциональность как и в любой другой системе требует настройки и доделки. А результат всегда зависит от возможности выбрать хороших специалистов. В данном случае вариант 2 обычно лучше. Система – это сложное решение. Распространенная система – это гарантия того, что система вообще может быть запущена в эксплуатацию с относительно небольшими затратами. Про другие системы такая информация может быть как правдивой, так и подделанной.
Лучше иметь собственную команду выполняющую внедрение и поддержку. Это будет гарантией, что наше решение не попадет к конкурентам. Специалист в штате обойдется дешевле чем внешний консультант. Грамотная консалтинговая компания решит нам все проблемы. Такие компании дорожат своей репутацией. Ни решение, ни нашу информацию ни кто не украдет. Напрашивается промежуточный вариант, (он есть во всех учебниках по IT менеджменту): Даже правильную консалтинговую компанию, нужно правильно озадачить. И контролировать ее результаты.
Нужно сертифицировать своих специалистов. Это позволит им грамотно решать задачи проекта. К тому же это позволит сохранить коллектив, т.к. повысит у специалистов ощущение самореализации и ощущение благодарности своей компании. Нужно взять на работу сертифицированных специалистов, они будут грамотно решать задачи. А если сертифицировать тех которые уже работают, то они потребуют большую зарплату или уйдут работать к конкурентам. А что такое сертификат? Это что то типа грамоты? Такие грамотны приятны сотрудникам, так что ощущение самореализации у них действительно повыситься.
Нужно иметь одну систему в которой вести и управленческий и бухгалтерский учет. При этом проблема интеграции управленческого и бухгалтерского учета отсутствует, всего одна система – значит меньше затрат на поддержку. Нужно иметь две разные системы одна для бухгалтерии другая для управленческого учета. Существуют типовые решения по интеграции между этими системами, так что это не проблема. Зато особенности бухгалтерского учета, которые подвержены постоянным изменениям не будут мешать управленческому. Для малых и средних предприятий две системы – это более эффективное решение – т.к. надо учитывать множество того, что не имеет отношения к бухгалтерии. А для крупных предприятий, а особенно тех которые выходят на IPO нужна одна система, чтобы бухгалтерская отчетность не расходилась с реальным состоянием дел.

Можно привести еще множество подобных примеров, да и подходы к вопросу могут быть разными, но важен результат. По нашим наблюдениям хорошо-внедренная система дает эффект помогающий бурному росту, однако определить какую часть этого роста можно приписать ERP сложно (методики отсутствуют, а конфликты с другими отделами, которые припишут заслуги себе – будут наверняка). И все же надо довести проект до внедрения, или другими словами, заставить интегратора сделать то, что он обещал.

Фокусы в отношениях с Интегратором (отсутствие пресс-релиза – это событие?)

“…Как известно, драконов не существует. Эта примитивная констатация может удовлетворить лишь ум простака, но отнюдь не ученого.”

Станислав Лем, “Кибериада”

При взаимодействии с Интегратором Клиенты делают большую ставку на то что Интегратор заинтересован в положительном пресс-релизе. Конечно заинтересован, но в деньгах клиента он заинтересован еще больше. А если пресс-релиза не будет дурного в этом нет, принцип сарафанного радио здесь не работает.

Внедрение ERP делается совместными усилиями Заказчика и Интегратора. Такова технология процесса, связанного с реорганизацией бизнеса, за которую Интегратор не отвечает. Обычно, это явно записано в договоре, и это логично, ведь Консультант не может обязать сотрудников Клиента делать что либо. Но если что то пойдет не так, Интегратор всегда докажет, что виноват не он а Заказчик (вне зависимости от того, кто же виноват на самом деле).

Во многих проектах, есть открывающий пресс-релиз и нет закрывающего. Приходит информация, в виде слухов, что какой либо проект завален. Но это предположение, а не событие. Нет точки, после которой можно делать заявление, что внедрение не состоялось. Сторонний наблюдатель может для себя придумать тысячи причин, по чему нет результата: закончились деньги у Заказчика, были пересмотрены объемы работ, или результат ожидается с минуты на минуту…

А успешное внедрение – это событие, и официальный пресс-релиз кочует из издания в издание. Т.е. невыполненный проект репутацию Интегратора не портит! Исключением является только судебное разбирательство – а таких случает единицы (большинство интеграторов хорошо готовят документы и Заказчику не за что зацепиться юридически). Интеграторы очень много внимания уделяют вопросу подготовки почвы для отступления и тратят уйму времени на подстилание соломки. Эти усилия такие мощные, что напоминают анекдот про пароход, который не смог плыть из за инженерной ошибки- вся мощность уходила в гудок. Если документы о том, что интегратор не виноват готовятся еще до заключения договора, какой результат можно планировать?

Все это Интегратор делает ради сохранения репутации. Но для рекламной компании ему надо иметь несколько пресс-релизов об успешных внедрениях, а что там происходит (произошло) с остальными проектами – не так важно… А вот что важно, так это выглядеть серьезной научной организацией.

Точные расчеты от фонаря

“…атаковав проблему методами точных наук, выявил три типа драконов: нулевых, мнимых и отрицательных. Все они, как было сказано, НЕ существуют, однако каждый тип – по-своему.”

Станислав Лем, “Кибериада”

Наукообразие, как я уже говорил, – хороший способ набить себе цену. Наукообразием изобилую не только пресс-релизы но и коммерческие предложения и даже договора. Например на клиента положительный или отрицательный эффект производит дизайн договора. Я бы охарактеризовал феномен так: чем больше в договоре непонятных пунктов, тем более уважительно к нему относится юрист клиента. Интересно, этот подход действует только на рынке системной интеграции, или он встречается и на рынках других инженерных решений? Я ни кого не хочу обидеть – и рекомендую всем Заказчикам нещадно резать договоры Интеграторов. Нужно максимально расчистить и сделать понятным юридическое поле в котором будет идти работа. Других инструментов повлиять на Интегратора может не оказаться, особенно после того, как бюджет проекта будет исчерпан.

Кстати о бюджете: я много раз слышал, что нельзя просить за проект круглую сумму. Приведу пример: пункт договора гласит: “…стоимость услуг по настоящему Договору $274363 доллара США. Стороны допускают отклонение не более чем на 10%…”. Но 274363 * 10 % это почти 30 тысяч. А зачем тогда точность до одного доллара? Почему нельзя было написать 275 000? И сразу стало понятно, что проект мерили с точностью до 25 000 долларов. Ошибка пустяковая, но очень показательная. Если ты называешь круглую сумму, то клиент может подумать, что ты взял ее от фонаря. Кстати по такому договору еще 10% интегратор обязательно забирает. Всегда найдется масса технических причин, почему отклонение пошло в нужную сторону.

А цифра действительно берется от фонаря и с запасом, ведь сложность в деталях, которые в начальный момент не известны.

Выбираем ERP (о подкупе должностных лиц)

“С точки зрения банальной эрудиции не следует нивелировать флуктуации паранормальных эмоций.”

Студенческий фольклор

В любых инженерных системах высокой сложности ошибки допущенные на начальном этапе, т.е. на этапе проектирования, выливаются в огромные проблемы и убытки на этапе запуска и эксплуатации. В нашем случае первым ключевым решением – будет выбор технологии, т.е. системы, которая будет внедрена. Однако этот процесс всегда превращается в театрализованный фарс.

Руководитель предприятия, не хочет и не обязан вникать в технические детали, но кому можно доверить такое дело? Вопрос обычно стоит шире: кому можно доверить ключевые решения по проекту? Я знаю немало опытных и квалифицированных начальников ИТ однако обращаю внимание на отсутствие системного образования по этим вопросам и на отставание науки занимающейся проблемами автоматизации учета. Как следствие у всех есть свои прорехи и перекосы в восприятии ИТ действительности. Эти люди воспитаны на той же ярмарочной площади, и над тем чтобы сформировать у всех правильное мнение работают мощные отделы рекламы крупных корпораций.

Разумно доверить дело тому, кто достиг результатов на другом проекте. Но каждый проект индивидуален, а значит есть риск (получивший подтверждения на практике), что на другом проекте может уже так хорошо не получиться. Вопросы информационных учетных систем это прежде всего умение управлять информацией и понимание принципов работы сложных систем. Но большинство специалистов с хорошим опытом в ERP не имеют твердых знаний в области Теории Информации, Теории Хаоса, Комбинаторики, Теории Автоматического Управления, Теории Множеств и др. Любой, реально сложный проект может оказаться им не по плечу.

Есть и другая опасность – специалиста будут подкупать. Все начальники ИТ с которыми я знаком – это неподкупные люди. Это верно если мы имеем в виду бытовое понимание честности. Но существуют профессиональные школы обучающие методикам правильного подкупа и умениям войти в доверие. Это обязательные навыки государственных спецслужб. Эти навыки просачиваются в коммерцию, когда речь заходит о проектах стоимостью сотни тысяч долларов. Чтобы противостоять такому подкупу не достаточно быть просто честным человеком. Опытные лоббисты готовят объект, и объекту кажется что к нужному решению он пришел самостоятельно.

Конечно купят, и он выберет не то что надо, ведь определить что именно надо не возможно. Я уже писал о бессмысленности сравнения систем по модулям, т.к. названия модулей и их рекламное описание ни чего полезного не несут. Наполнение модулей приобретает смысл в процессе применения системы к задачам. Но этот процесс составляет основу проекта. Нельзя же его повторять, ведь это основная часть стоимости? Нельзя, но кто не внедрил – вынужден повторять…

Опытные руководители предприятий, особенно те, кто уже обжегся все эти вещи чувствуют и вынуждены принимать участие в выборе ERP. И это правильно, т.к. выбор системы не такой уж и сложный вопрос. За 10 лет в теме, у нас с коллегами по цеху выработался только один четкий критерий: это должна быть распространенная система. Это единственная гарантия, что система может быть внедрена в реальные сроки с реальным бюджетом. Это так же гарантия, что вы сможете выбрать специалистов – они в каком то количестве будут присутствовать на рынке, а с нераспространенной системой с наличием специалистов возможны затруднения. К сожалению, рекомендация “выбирать распространенные ERP” не способствует развитию рынка и усугубляет проблему диктата гигантов, но таковы реалии.

Итого

“Все действующие лица, места и события в этой книге – подлинные. Некоторые высказывания и мысли по необходимости сочинены автором. Ни одно из имен не изменено ради того, чтобы оградить невиновных, ибо Господь Бог хранит невинных по долгу своей небесной службы.”

Курт Воннегут, “Сирены Титана”

Многие решения по ERP проекту диктует среда, которая состоит из псевдо науки, рекламы, шустрых продавцов и специалистов самоучек. Это уже третья статья, которая построена так что любой интегратор должен публично открещиваться от всего, что здесь написано. Если научных организаций на рынке нет, это не значит что все проходимцы. Будем надеяться, что статья пробудит у кого то совесть и он станет относиться к работе честнее. А многие делают это и сейчас, по долгу своей службы, ведь по другому работать нельзя в среде, где нет объективных критериев результата.

Все не так уж и плохо. Выбрать себе систему совсем не сложно, а кризис должен умерить аппетиты интеграторов. И я надеюсь, что в скором времени начнут пробиваться здоровые научные ростки, которые придадут более системных характер рынку ERP и сделают результаты проектов более предсказуемыми.