Подготовка проекта Описание бизнес-процессов Команда внедрения Выбор платформы Состав ERP-системы Выбор Исполнителя, бюджет ТЗ и объем проекта Разработка проектных решений Интеграция Обучение пользователей Тестирование системы Опытная эксплуатация Рабочая эксплуатация Экономический эффект

 

Подготовка ERP-проекта или предварительный этап... Это в первую очередь предпроектное обследование и задание на внедрение (стратегия-цели-задачи внедрения, концепция-ограничения проекта, оценка экономической эффективности, размеры ERP-проекта, необходимые условия для внедрения - в т.ч. степень готовности самого Заказчика).
  Под целями проекта обычно понимают три фактора: качество, сроки и бюджет. Затраты на разработку стратегии, целей и задач внедрения ничтожно малы по сравнению с возможными потерями в результате неудачного внедрения из-за отсутствия у Вас или не их четкой формулировки стратегии, целей и задач внедрения. ERP-систему нужно проектировать, ориентируясь на цели компании, последовательно определять вид и характеристики информации, необходимой каждому уровню управления (конечно, начиная с высшего руководства Заказчика).
  В мировой практике существует устоявшаяся градация ERP-проектов, исходя из такого параметра, как размер предприятия. С учетом российской специфики, отечественные эксперты предлагают градацию ERP-проектов не в зависимости от оборота предприятий, а исходя из количества будущих пользователей системы (именно системы, а не штатных сотрудников компании). Соответственно, по этой методике к категории малых мы относим проекты, рассчитанные на численность ERP-пользователей до 100 пользователей, средних — до 200, и крупных — свыше 200 пользователей. Определение будущего количества рабочих мест с учетом всех планов развития компании становится важнейшей задачей.
  По эффективности важно сопоставлять расходы на автоматизацию того или иного процесса, учитывая его место в будущей ERP-системе, с итоговыми экономическими результатами проекта в целом. То есть необходимо ответить на вопрос, что даст ведение учета соответствующих операций в ERP-системе или предоставление таких-то данных такому-то менеджеру? Каких потерь это поможет избежать? Как повысит эффективность используемых ресурсов? Какие резервы позволит вовлечь в деятельность Заказчика?
  Конечно, ERP-решение своими функциональными возможностями способно охватить практически все основные бизнес-процессы вашей компании и вывести их на новый качественный уровень. Но какова степень готовности системы управления компанией к работе с ERP? Все ли Вы будете внедрять сразу или разобьете по части? Какой функционал точно останется, какой обсуждается, а кокой точно нужно купить? Какие документы (положения) необходимо внедрить до начала проекта? Выходной документ этапа всего один, но очень большой -"Задание на внедрение ERP" и утверждается он чаще всего не только Генеральным директором, но и Учредителями.
  Важной задачей этапа является определение требований к программному обеспечению с учетом особенностей предприятия. При ограниченном лимите средств требования могут быть определены на основе существующих у Заказчика регламентов и описаний бизнес-процессов, должностных инструкций и другой документации, содержащей информацию о бизнес-процессах и документообороте компании.
  Мы готовы помочь Вам с каждой задачей.

Описание бизнес-процессов... Мы обращаем Ваше внимание на то, что под ERP-системой сейчас подразумевается не столько компьютерная программа сама по себе, сколько методология эффективного планирования и управления. Соответственно, установке и настройке ПО предшествуют весьма длительные этапы обследования, моделирования, а также под- или перестройки бизнес-процессов. Т.е. есть необходимость проведения мероприятий, которые принято называть "реинжинирингом бизнес-процессов" (BPR).
  В России есть две крайности - или компания, внедряющая ERP-систему, соглашается с фирмой-Исполнителем на реинжиниринг всех бизнес-процессов и их подчинение требованиям базовой функциональности выбранной системы, или компания настаивает на 100% сохранении сложившейся практики работы и соответственно - кардинальном переписывании кода выбранной системы. Но если сильно изменить программный продукт, то вы в дальнейшем будете вынуждены заниматься сопровождением системы самостоятельно, так как новые версии, поступающие от производителя, не будут учитывать сделанных вами модификаций. Эти две крайности пополняют список причин неудач при внедрении ERP-систем.
  Затраты на построение модели деятельности предприятия сильно различаются от проекта к проекту. Но отсутствие качественной модели может привести к полному или частичному перевнедрению системы, что в свою очередь взвинтит затраты и конечная стоимость проекта окажется в несколько раз больше, чем предполагалось вначале.
  Анализ деятельности предприятия - довольно емкое понятие. В данном разделе под анализом деятельности понимается следующее: сбор и представление информации о деятельности предприятия в формализованном виде, пригодном для выбора и дальнейшего внедрения автоматизированной системы. В зависимости от выбранной стратегии автоматизации предприятия технологии сбора и представления информации могут быть различными. Итоговое представление информации на этапе анализа деятельности играет одну из ключевых ролей во всей дальнейшей работе. Мы советуем, чтобы анализ предприятия закончился построением набора схем, соответствующим IDEF-стандартам. Иногда их набор называют "As-Is" (как есть).
  Мы готовы помочь Вам и описать-систематизировать ваши бизнес-процессы, и установить разумный баланс. См. наше предложение подробнее...

Команда по внедрению... Процесс внедрения ERP-системы очень дорог. Поэтому команда по внедрению должна обладать поразительной пропускной способностью, не задерживая даже на день решения ни одной возникающей проблемы. Как конкретно это будет сделано — удел конкретного проекта. Но есть весьма распространенные ошибки...
  Ответственные лица со стороны Заказчика - это "Куратор проекта", "Руководитель проекта" ("Менеджер проекта", "PM-менеджер"), "Руководители рабочих групп".
  "Руководитель проекта"— это ключевая позиция внедрения. Руководитель курирует ведение проекта, отслеживает работы-сроки-документы, ведет переговоры. Загрузка - 100% рабочего времени и его единственной работой - будет проект. Он управляет временной командой, причем ее состав за время проекта может изменяться, а участники — иметь двойное подчинение: менеджеру проекта и своему функциональному руководителю. "Руководитель проекта" часто даже вовлечен в процесс обсуждения архитектурных особенностей кода. Главная ошибка Заказчика - требование к руководителю проекта быть специалистом в предметной области проекта. Но навыки проектного управления гораздо важнее знаний отраслевой специфики. Менеджер проекта должен обладать незаурядными лидерские качествами, иметь аналитические способности и опыт профессионального руководства проектами. И только.
  "Куратор проекта"- это кто-то из главного руководства компании. Загрузка - 10-15% рабочего времени. Многие Заказчики повторяют ошибку назначения ответственным кого-то из директоров. Того, кто увы - физически не сможет выделять на проект время. Но тогда проект останется без стратегического руководства, а "Руководитель проекта" останется без поддержки и утонет в проблемах. Обязательно должны быть обстоятельные и регулярные совешания (не реже еженедельных) у "Куратора проекта". Типичная ошибка Заказчика, приводящая к затянувшимся либо незавершенным проектам, а порой и к их закрытию заключается в том, что руководители, формально сделав первый шаг, все остальное поручают выполнить своим сотрудникам, созерцая со стороны в ожидании результата. И как ее следствие, следующая ошибка Заказчика - отсутствие явно выраженной поддержки своего Руководителя в многочисленных спорах с Исполнителем. Позиция "арбитра" приводит к затягиванию решения вопроса, а иной раз и к уходу "Менеджера проекта".
  "Руководители рабочих групп"- это Директора департаментов, Начальники Управлений, Руководители направлений - т.е. те, кто является владельцами ключевых бизнес-процессов. Они возглавляют профильные рабочие группы Заказчика и выдают решения Исполнителю. Загрузка - 5-10% рабочего времени. Желательно, чтобы эти люди обладали не только высокой квалификацией, но и желанием, стремлением к изменениям, энтузиазмом, по возможности были психологически совместимы. Если ведение проекта поручается им на общественных началах, из этого ничего не получится – это большая и ответственная работа, требующая максимального "погружения" членов рабочей группы в процесс внедрения. Нагрузка на каждого из них возрастает в три-четыре раза. Поэтому необходимо заранее продумать систему их мотивации. Ошибки Заказчика -"работа в рабочем режиме" и "если затевается ИТ-проект, то и заниматься им должны исключительно сотрудники отделов IT-АСУ-внедрения". .
  Важно, что команда Заказчика (Ответственные лица, сотрудники отдела внедрения) ни в коем случае не должна меняться или сокращаться. Их увольнение - смерти подобно. Ошибки Заказчика - "найдем другого" и "справитесь и так" приводят к срыву проекта, а экономия 10-20 тысяч ЗП выльется в потерю миллионов. Необходимо провести обучение членов рабочей группы с тем, чтобы они получили общие представления о методах управления, в частности, о концепции MRP II, а также о методах анализа существующих бизнес процессов и о том, какие задачи можно решить с помощью ERP-системы.
  Еще важно, что многие проекты проваливаются не столько из-за своей технологической сложности, а сколько из-за плохих коммуникаций. Пусть все ключевые лица проекта будут иметь лаптопы и мобильный выход на сеть. Это очень правильно — быть быстрыми.

Выбор платформы... Каких-либо жестких методик, позволяющих предприятию выбрать для себя то или иное решение, практически не существует. Обычно при выборе необходимо учитывать множество взаимосвязанных факторов, влияние которых друг на друга весьма неоднозначно. К сожалению, требования к системе определяются выбором платформы. Именно так, а не наоборот. Попытки сделать "чистые", рафинированные, требования встречаются регулярно. Но как только появляется мало-мальски убогая детализация, так сразу требования переходят в чисто техническую плоскость с формулировками.
  По данным исследования IDC, объём российского рынка интегрированных систем управления предприятием (ИСУП) в 2011 году составил $927,05 млн. Понятно, что каждый ERP-производитель позиционирует свою систему как самую лучшую. Однако при детальном рассмотрении приходится принимать решение не вообще, а лучшую для "сейчас" и для компании. Внедрение предполагает серьезные изменения в бизнес-процессах компании, обусловленные методологией внедрения и имеющейся функциональностью внедряемой ERP-системы.
  Самое главное, что почти все Заказчики путают "систему" и "платформу". На большинстве российских предприятий ERP-решение - свое, выполненное не путем настроек, а написанное на встроенном языке программирования. Т.е. этот программный код не поддерживается никем, кроме его авторов. И совершенно не гарантируется совместимость этого кода со следующими версиями базовой системы.
  При выборе системы необходимо оценивать, насколько трудоемко вносить в нее изменения, которые, несомненно, будут необходимы в условиях быстроизменяющихся рыночных потребностей. В системе со сложными формализованными внутренними процессами такого рода изменения производить довольно трудоемко. Так же необходимо обратить внимание на наличие удобного встроенного языка программирования, который облегчит процесс адаптации.
  В 2011 году (свежее данных нет) по данным IDC-исследования в России популярна пятерка лидеров систем автоматизации бизнеса: "SAP ERP" (ранее SAP R/3)= 47,8%, "Oracle E-Business Suite" (OEBS)= 7,5%, "Microsoft Dynamics AX" (Microsoft Axapta)= 6,9%, "Галактика" = 1,8% и "1С:Предприятие 8"= 31,6%. IDC считает, что российский рынок ИСУП в ближайшие пять лет будет ежегодно расти в среднем на 17,8%. Не входят в пятерку "Sage Group" с Baan-ом, "Парус", "БОСС-Корпорация", "Microsoft Dynamics NAV" (Microsoft Navision), "Scala", "Avarda ERP", "CARLO", "IFS Applications".
  Важно, что на многих предприятиях уже работают ERP-системы на базе "1С-8". Как так, ведь система "1С 8"- это НЕ полноценная ERP-система? Во-первых, следует присмотреться к функциональности системы, поскольку очень часто под видом ERP-систем внедряются обычные учетно-регистрационные функции. Т.е. если система изначально была ориентирована на учетно-регистрационные задачи, то система ERP-класса, ориентированная на задачи планирования ресурсов и управление жизненным циклом заказов, из нее не получится. ERP-система должна содержать встроенные реакции по всему контуру, включая производство, логистику, финансы. Если ничего не происходит, а данные просто фиксируются в базе, то для этого ERP-система не нужна. На базовом архитектурном уровне в качестве базового элемента в "1С" выступает документ, что полностью устраивает и бухгалтера и учетных работников, но не может устраивать руководство предприятия, управляющих производством и сбытом. В основе ERP-систем лежит жизненный цикл информационных объектов, прежде всего, заказов, а в развитом виде (в рамках BI-систем)- в основе лежат бизнес-процессы. Из учетно-регистрационной системы ERP-систему нормально сделать нельзя. Но ведь "1С" является не системой, а платформой с встроенным языком программирования, поэтому написать на ней можно что-угодно, хоть расчет траектории баллистической ракеты. Мы считаем, что написать ERP-систему на базе "1С-8" хотя и можно, но - не нужно. Более того, при начале работ с "1С" вообще неизвестно, во что обойдется проект в целом (для других систем можно примерно оценить объем доработок, поскольку они уже содержат всю необходимую функциональность).
  Еще важно, что принципиальная разница между "Microsoft DAX" и "SAP ERP" состоит в том, что в одной системе одной присуще изначальная ориентация на адаптируемость к требуемым процессам предприятия, а в другой - на заложенные изначально. И каждый Заказчик выбирает, что ему предпочтительнее. Для систем класса "SAP ERP" общепринятая практика внедрения - притягивание процессов компании к имеющейся богатой функциональности системы, что влечет за собой серьезное увеличение затрат компании на управление проектом внедрения, а также изменениями собственных процессов в соответствие жестко реализованным алгоритмам.
  Неверный выбор ERP-платформы при равной стоимости альтернативного продукта может взвинтить затраты на внедрение и эксплуатацию. Т.е. решение для автомобильных дилеров конечно можно переписать для фармцевтики. Вопрос в том, во сколько это обойдется.
  Мы, как Ваши консультанты поможем Вам подготовиться к выбору необходимой информационной системы, а также сформулировать критерии отбора компании, которая будет внедрять эту систему. При нашей помощи возможно создание у Вас ERP-системы, которая будет настоящим произведением искусства, вышедшим из рук команды внедрения.

Состав ERP-системы... ERP-система — увы, совсем не "коробочная" программа, как например Microsoft Office, которую можно с равной степенью эффективности установить на компьютерах любого предприятия. Современные ERP–системы состоят из более чем десятка огромных блоков (модулей)— от финансового до управления персоналом.
  В состав ERP-системы входит множество составляющих, которые обычно не попадают в состав учетных систем. Какого-либо одного документа, описывающего требования к современным ERP-системам, практически не существует. Как правило, ERP-решения включают возможности по автоматизации таких процессов, как управление финансами (ведение финансового учета и оперативное управление финансовыми потоками предприятия), управление производством и материально-техническое обеспечение (прогнозирование и управление спросом, объемно-календарное планирование, укрупненное планирование мощностей, планирование потребностей в материалах и планирование потребностей в мощностях, цеховое управление и диспетчеризация производства), управление затратами, управление закупками, продажами и запасами, управление проектами (формирование проектных планов работ, планирование задач и проектных ресурсов), управление персоналом, управление производственными проектами и программами, а также проектирование продукции и технологических процессов.
  Для современных ERP-систем характерно развитие новых функциональных возможностей, связанное с выходом за традиционные рамки автоматизации процессов внутри предприятия. В основном добавляют автоматизацию: логистических цепочек (т.е. процедуры Supply Chain Management, SCM - управление цепочками поставок), взаимоотношений с клиентами (Customer Relationship Management, CRM - управление взаимоотношениями с клиентами), управление складскими запасами (Warehouse Management System, WMS - ведение полноценного складского учета, поддержка уровня "страховых запасов" на складах, оптимизация складских остатков).
  Мы рекомендуем сначала упорядочить процесс выбора ERP-системы для компании. Например через модель создания набора критериев. По 4-м видам: функциональные, технологические, организационные, рыночные. Эти критерии, в свою очередь могут объединяться в группы, либо классифицироваться по областям применения. Например, требования:
      a. Функциональные: FrontOffice, ERP, CRM, WMS, BI.
      b. Технологические: к ОС сервера, требования к ОС клиента, каналы связи, web интерфейс.
      c. Организационные, рыночные: наличие на рынке труда специалистов и их стоимость; стоимость обучения людей; количество вендоров-разработчиков системы; конкуренция на рынке интеграторов; история деятельности интегратора; стоимость лицензий; стоимость внедрения; стоимость поддержки.
  Конечно, не все указанные функции, требования могут быть применимы к вашей компании, но в любом случае постарайтесь включить все разумные высказанные требования и критерии.
  Важно помнить, что ERP - это система планирования, управления ресурсами. И потому она оперирует ресурсами на оси времени не только в разрезе "было" или "есть", но и в разрезе "будет". В этом принципиальное отличие ERP-системы от учетной системы (вроде систем, нацеленных на автоматизацию бух.учета).
  Важно помнить, что для полномасштабного внедрения ERP-систем потребуется не один год. Ошибка Заказчика - поверить в короткие сроки, в обещания Исполнителя "сделать быстро"(зафиксированные в Договоре). Но не переживайте - мы Вам поможем, обращайтесь.

Выбор Исполнителя и бюджет... Это определение типов лицензий, списка возможных исполнителей, переговоры, расчет бюджетов, проведение тендеров среди вендоров, согласование методология внедрения, подписание контракта...
  Контракт на внедрение ERP-системы — это четыре больших стоимости. Принципиальная ошибка Заказчика - сумма внедрения будет равна сумме договора. Не будет, коллеги - никогда не будет! Бюджет внедрения можно систематизировать на каждом из этапов в следующих разрезах:

1. Лицензии на блоки ERP-системы. Это собственно сама программа со стандартной функциональностью. Но есть простые лицензии и есть расщиренные; для серверов и для рабочих станций; для отдельных блоков и для СУБД; дополнительное ПО (консолидации финансовой отчетности; подготовки и контроля бюджетов; управления документооборотом). Дополнительное не потому, что такового нет в принципе, а поскольку требуемой функциональности нет в "базовых" блоках системы;
2. Работы Исполнителя. Это дополнительное программирование-настройка и обучение сотрудников, осуществляемая вендором;
3. Оборудование ("железо")- покупка необходимого аппаратного обеспечения. Можно разделить:
   • компьютерное обеспечение для серверов баз данных, приложений (для 3-х уровневой клиент-сервер архитетуры), web-серверов (при реализации приложений для в интернета)
   • коммуникационное оборудование для поддержки требуемой ИТ инфраструктуры и требований к безопасности передачи данных;
   • покупка новых или усовершенствование старых рабочих станций пользователей
   • прочее вспомогательное компьютерное обеспечение, включая средства резервирования данных, принтеры, факс-модемы и т.п.
4. Техническая поддержка от Исполнителя. Это дополнительное , осуществляемая вендором. Объем и стоимость может различаться в десятки раз;
5. Внешний консалтинг (услуги внешних консультантов) и общепроизводственные затраты;

ТЗ и объем проекта... Техническое Задание или как его еще называют "Анализ и дизайн"/"Доработка концептуального бизнес-проекта и проектных решений".
  Целью данного этапа является детальная техническая разработка требований к ERP-проекту (т.н. "ToBe"/"Дизайн-решение"), обеспечивающей функционирование всего спектра бизнес процессов, которые должны быть охвачены системой, а также полный набор задач, функций и операций. Весь необходимый функционал системы систематизируется и группируется по функциональным участкам, затем для каждой функции принимается решение, каким образом она будет реализована в системе - с помощью стандартного функционала, существующего решения Исполнителя или дополнительно разработанного функционала. На основании этого решения составляется ТЗ, чаще всего - по блокам.
  Первый путь (редко)- разработка документа специальным штатом сотрудников Заказчика. Второй путь (обычный)- обследование проводится Исполнителем как в виде интервью, так и в виде изучения Исполнителем предоставленных документов. Ошибка Заказчика - все, что сказано-передано, обязательно будет реализовано. С чего бы? Практика показывает обратное. Необходимо не только сделать реестр переданных документов, но и вести его на следующих этапах с информацией, где и как это реализовано. Надо понимать, что реально никакой Исполнитель не будет выполнять пожелания Заказчика 1:1 - он просто подгоняет их к базовому существующему или имеющемуся функционалу. Для составления Технического задания может помочь ГОСТ 34.201-89.
  При написании следует помнить, что полученная вследствие доработок и переработок система теряет свою надежность. Соответственно, резко возрастают риски ошибочной обработки вводимой информации. Более того, никакой пользы от автоматизации неэффективных бизнес-процессов компании не будет. Наоборот, она лишится возможности совершенствовать свою деятельность, т.к. будет зажата в жесткие рамки работы программы. В этой связи крайне важно правильно определить оптимальное соотношение между реинжинирингом бизнес-процессов и доработкой системы.
  Специалистам Заказчика следует крайне внимательно отнеситесь к каждому слову в данном документе, при необходимости - расшифровывать каждый абзац, каждый термин. Ошибка Заказчика - поверить на слово "да, сделаем". 50% успеха дальнейшего внедрения ERP системы зависит от этого этапа.
  Часто Исполнителями практикуется вынос наиболее трудоемкого функционала за рамки "ToBe"/"ДР", пытаясь т.о. отыграть снижение прибыли, потерянной при выигрыше тендера. При этом Исполнители категорически отказываются выполнять эти работы в рамках проекта. В данной ситуации рекомендуем этап ТЗ с фирмой-вендором обязательно закончить (т.е. получить технический текст), включая описания доп.работ, но все дальнейшие работы - передать другому вендору.
  Поскольку техническое задание – это главный документ, который ограничивает объем работ при внедрении ERP-системы на предприятии, все отсутствующее в нем будет считаться дополнительными работами (с лишней оплатой). Конечно, сделать все идеально не получяется ни у кого, но при нашей помощи можно сократить ошибки до минимума. Обращайтесь, поможем!

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

• Разработка и доработка операционных и технологических инструкций (иногда называется "Функциональным дизайном"). Т.е. Исполнитель должен создать документ (чаще набор документов), где на языке и терминологии системы описывается порядок осуществления в системе процессов, функций и операций, закреплённых в ТЗ. Кроме того, документ содержит описания настроек системы, проделанных Исполнителем для того, чтобы система выполняла установленные функции.
• Демонстрации контрольных примеров. От Заказчика на этом этапе требуется подготовить данные для контрольно-тестовых примеров работы внедряемого программного обеспечения (желательно как сквозной по компании, так и детальные по каждому функциональному блоку). Итоги демонстраций фиксируются в Протоколах. Ошибка Заказчика - просмотр работы примера только на презентации, без дополнительной проверки на рабочих местах пользователей. Нередки случаи фальсификации Исполнителем итогов контрольного примера.
• Замечания, указанные пользователями - фиксируются и обсуждаются. Согласованный реестр (например xls-файл) рассматривается совместно представителями Заказчика и Исполнителя, и каждое классифицируется на принятые к исполнению (со сроком) и отклонённые (при этом Исполнитель обязан аргументировать - почему, а Заказчик может не согласиться). Далее составляется план-график устранения принятых замечаний и демонстрации исправлений Заказчику. Большинство вендоров-поставщиков не знают и не хотят знать проблемы клиента, погружаться в тонкости бизнес-процессов. Ошибка Заказчика - верить в слова Исполнителя типа "конечно все это есть в системе... и это лучше сделать немного позже...". Нет там этого функционала и ничего не будет сделано!
• Шаблоны для ввода начальных (т.н. исторических) данных. Сначала определяются принципы миграции начальных данных. Как правило, вся справочная информация и начальное сальдо заносятся в систему через промежуточные таблицы. Структура и источник этих таблиц в реалии определяется возможностями Заказчика по их заполнению, а также требованиями к системе, выявленными на этапе ТЗ. Часто в качестве шаблонов данных используются файлы в Excel-формате (*.xls).
• Отчеты и OLAP-кубы. На этапе ТЗ в каждом функциональном "ToBe"/"ДР" были описаны принципиально важные для Заказчика отчеты и их формы. Т.е. есть OLAP-ы и есть отдельные отчеты. К сожалению, очень часто Исполнитель старается использовать стандартные OLAP-ы системы, но из-за этого вырастает количество отдельных отчетов (с соответствующими требования дополнительных денег). Ошибки Заказчика - не предоставление Заказчику измерений по каждому OLAP-кубу, не предоставление полного реестра отчетов системы, невмешательство в перенос.

Интеграция... Единая ERP-система без интеграции с другими системами или бизнес-процессами является лишь легендой. Каждое внедрение предполагает некоторую интеграцию иными системами и бизнес-процессами, которые выходят за рамки самой ERP-системы. Такая интеграция должна быть предусмотрена заранее, и не только с точки зрения внедренцев (совпадения платформ и т.д.), но и со стороны бизнес-процессов. В противном случае система будет раздробленной и непоследовательной, что подорвет весь смысл ERP.
  Интеграционные механизмы обычно описываются в отдельных документах, где каждая внешняя система описана отдельно (например "Техническое задание на интеграцию CRM" или "Техническое задание на интеграцию WMS"). За основу берётся предварительная схема интеграции, описываемая в ТЗ - она является логическим ограничением данного этапа. Под интеграционным механизмами понимается разрабатываемый интеграционный интерфейс (программный код), режимы и периодичность интеграции, схема интеграции.
  Поскольку часто интегрируются продукты разных компаний (поддерживаемые разными вендорами) обязательно необходим документ разграничения действий и сроков реагирования. С механизмом разрешения спорных вопросов.
  По завершению каждой разработки интеграции осуществляется тестирование (используются тестовые данные), вплоть до полномасштабного использования механизмов интеграции на части реальных данных. По итогам тестирования подписывается протокол тестирования интеграционных интерфейсов. Выходные документы этапа (умноженное на кол-во систем):
      · Техническое задание на интеграцию;
      · Протокол тестирования интеграционных интерфейсов;

Обучение пользователей... Как правило, речь идет об обучении небольшой части сотрудников Заказчика, т.н. 7-10 ключевых пользователей. Для этого разрабатывается и реализуется адаптированная к потребностям Заказчика программа обучения ключевых пользователей. Подготовка проводится Исполнителем на настроенной ERP-системе в рамках отдельных функциональных участков. Обучение должно быть адаптировано не на изучение отдельных модулей и выполнение отдельных операций, а только - к конкретной ситуации, ориентируясь на ролевые задачи и должностные обязанности персонала. Каждый тренинг должен длиться не менее 3-5 полных рабочих дней.
  К сожалению, Заказчик практически всегда допускает три принципиальные ошибки. Во-первых, обучать специалистов предприятия работе с новой внедряемой системой надо не к окончанию работ, а уже на начальных этапах внедрения (идеально - вообще до начала). Во-вторых, почему всего 7-10? Компьютерная грамотность в любой компании - весьма низкая (даже молодых тинеджеров), а для работы с ERP - вообще нулевая. То, что люди сейчас знают 10 кнопок в старой системе - никак не гарантирует их работы в новой. Наш совет - должно быть минимум два человека от каждого отдела компании. Во-третьих, освобождение обучаемых сотрудников на дни обучения от основной работы. Обучаться ERP урывками между своей работой - невозможно, это пустая трата времени. Да, все это - немалые затраты. Но иначе суммы ваших потерь будут в сотни раз больше. Были случаи и массовых увольнений, и когда фирма просто "вставала".
  В процессе подготовки этих пользователей должна быть достигнута главная цель - обеспечение эффективного использования всех возможностей новой системы.

Тестирование ERP системы... Процесс тестирования является одним из тех, для которых справедлива инвектива: "лучше никогда поздно". Для участия в тестировании Закзачику необходимо привлечь всех ключевых пользователей. Некоторые из них не выдерживают стресса от дополнительной интенсивной нагрузки и "ломаются". Одной из самых серьезных ошибок Заказчика является передача тестирования внешним ресурсам, тогда как оно должно быть выполняться ключевыми пользователями параллельно с проектированием и настройкой. Обязательны программа и методика испытаний, где описаны сценарии тестирования и ожидаемые результаты работы.
  Ошибка Заказчика - тестирование осуществляется только с целью проверки работоспособности системы, но при этом вообще не тестируется реализуемость организационных изменений, и не тестируются отчеты и документы.
  Тестирование бывает двух видов:
      · "Функциональное", в ходе которого производится проверка работоспособности всех возможностей системы;
      · "Нагрузочное", во время которого проверяется работоспособность системы на больших объемах обрабатываемой информации.
  После тестирования заполняется протокол проведения испытаний. Нагрузочное тестирование должен проводить эксперт по технологическим вопросам. После устранения выявленных недостатков производится повторное тестирование.
  Как бы печально не складывалось текстирование, обычно руководству докладывают, что "все хорошо", а "незначительные" проблемы будут решены в процессе ввода в эксплуатацию. Руководство не должно покупать на эти "сказки", так как одновременный ввод в эксплуатацию и решение системных проблем, обнаруженных в процессе тестирования -"невыполнимая миссия". Не надо бояться "воевать" с внедренцами. Самая знаменитая памятка в сети (автор - Максим Алферов) даже так и называется "Как бороться с внедренцами?".
  Ошибка Заказчика - обычно у любого Исполнителя в план проекта внедрения ERP-систем не закладывается время на исправления (до-настройку) системы по результатам тестирования.
  Советуем не забывать о казусе "mission impossible": основой причиной т.н. "усовершенствований" системы после ввода в эксплуатацию, существенно увеличивающих стоимость проекта, являются не "хотелки" пользователей и "точная" донастройка, а экономия на тестировании. Наши опытные советы помогут Вам избежать проблем.

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

• "Параллельная"- когда одновременно работают старая (или ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время - осуществляется переход на новую систему. Мы рекомендуем ее. В случае, если руководством Заказчика было принято решение осуществлять параллельный ввод данных в действующую и новую системы, в обязанности представителей Заказчика входит сверка отчётности, полученной из различных систем, выявление соответствующих расхождений. И совместно с Исполнителем - определение их причины.
• "Пилотный проект"- это стратегия, наиболее часто навязываемая Исполнителями. "Пилотный проекта"- это тактика стратегии "Скачка" (которая даже не рассматривается), но применяемая к ограниченному числу процессов. Область применения стратегии - небольшой участок деятельности. Такой подход действиетельно снижает риск. И одновременно снижает возможные проблемы у Исполнителя. По нашему опыту, компанию после использования именно этой стратегии ждет тяжелейший период (3-6 месяцев), чревытый многочисленными сбоями - вплоть до полной остановки предприятия. Вам это надо?
• "Узкое место"- это малая часть производственного процесса. лан внедрения выполняется только для "узкого места" и для людей, работающих в нем. Точность данных повышается - но только для изделий в этом "узком месте"; переподготовка- только для людей, работающих в нем; анализ эффект-затрат делается только для него и т.д. На наш взгляд, это стратегия для ERP-системы неприменима.

Рабочая эксплуатация... или "Промышленная эксплуатация ERP-системы"/"Ввод в эксплуатацию"/"Период стабилизации". ERP-система работает, все пользователи Заказчика начинают выполнять свои должностные обязанности только в ней. Проблемы этапа:
  Во-первых, у пользователей ERP-системы возникает безумно много вопросов - должен быть предоставлен легкий доступ к службе поддержки. Ошибка Заказчика - отсуствие массовой поддержки пользователей в период стабилизации (как правило, первые 1-3 месяца после старта). Т.е. не "горячая линия" Исполнителя, а специалисты Исполнителя, помогающие работать с системой. Своего штата - гарантированно никогда не хватит. И никогда ваш сотрудник (по сути - страшно малограмотный) не начнет "с ходу" работать в ERP, никогда -"чудес не бывает".
  Во-вторых, ваша очень сложная ERP-система только сейчас заработала с полной нагрузкой. С точки зрения какого-нибудь одного пользователя система - идеальна, но ведь этих пользователей у Вас сотни, да ещё и они разбросаны территориально, да ещё первичных документов генерируется большое количество, и интеграция с другим ПО выдает непонятки - вот тогда ваша красивая ERP на минимум полгода превратилась в головную боль всех и вся. Ведь внедрение современной ERP-системы на предприятии - это процесс, который может длиться несколько лет.
  Принцип любого Исполнителя, занимающегося внедрением ERP-систем: "внедрение никогда не заканчивается". Вы считали, что траты завершены и все уже ОК? Зря считали... Внедренцы считают совсем по-другому – переход на промышленную эксплуатацию должен стать торжественным событием, завершающим один этап работ и началом новых работ по масштабированию, совершенствованию текущего функционала, а так же по внедрению новых или не задействованных возможностей ERP-системы. Вот такая у них сверхзадача. Вам оно надо?

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

• снижение операционных и управленческих затрат на 15%;
• снижение затрат на 15%;
• снижение страхового уровня складских запасов на 20%;
• увеличение оборота на 25%;
• уменьшение дебиторской задолженности на 12%;
• увеличение оборота материальных запасов на 30%;
• увеличение оборачиваемости средств в расчетах на 25%;
• улучшение утилизации основных фондов на 30%;
• снижение коммерческих затрат на 35%;

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

• Установка тесных, рабочих отношений с Заказчиком — на всех уровнях, включая топ-менеджмент, руководителей ИТ-служб, специалистов подразделений и пр. Успех проекта возможен лишь в случае заинтересованного и конструктивного участия в нем сотрудников компании-заказчика.
• Наличие очевидных (реальных) результатов, особенно в случае крупномасштабных проектов, которые консультант должен продемонстрировать персоналу и топ-менеджменту.
• Профессионализм команды со стороны IT-консалтинга.
• Применение соответствующих проектных методологий, схем управления проектом.

С уважением
Дмитрий В. Белоусов
бизнес-консультант по ERP-внедрению
freelancer