Как не провалить проект внедрения ERP: 16 подсказок

Как не провалить проект внедрения ERP: 16 подсказок

Сергей Соловьев Менеджер интернет-проекта, Москва

Дабы избежать неточностей при внедрении ERP, исполнитель обязан «вскрыть сознание» клиента, а клиент – предельно честно ответить себе, для чего он ввязывается в проект.

Важный бизнес представить без ERP нереально. Современные ERP-совокупности (термин Enterprise Resource Planning переводится с английского как «планирование ресурсов предприятия») автоматизируют управление фактически всеми видами ресурсов, а также трудовыми, технологическими, маркетинговыми. Что особенно принципиально важно: такая автоматизация не делается заблаговременно, про запас.

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

Взор со стороны клиентов воображает Александр Козаржевский, начальник проектов с опытом внедрения серийных IT-ответов на производстве и в ритейле. Позицию разработчиков озвучивает Инна Петрова, начальник группы по внедрению ERP-совокупности в компании Legrand. Их пожелания редакция Executive.ru свела в таблицу, расположенную ниже.

Executive.ru: Что в первую очередь необходимо узнать клиенту у поставщика ERP-совокупности, и встречно, разработчику у клиента?

Инна Петрова: «Из-за чего?». Из-за чего вы сделали вывод, что вам нужна ERP-совокупность? Из-за чего эта, в случае если указывается конкретная?

Из-за чего обратились к нам?

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

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

  • Что именно внедряли?
  • Где, какой масштаб пользователей-и компаний заказчиков ваших IT-ответов?
  • В то время, когда? В случае если в далеком прошлом, имели возможность уйти те, кто добился этого успеха.

Принципиально важно кроме этого познание специфики процесса внедрения и нашего бизнеса:

  • Какой у вас подход?
  • Что выяснено в качестве рамок проекта?
  • Как контролируется движение внедрения ERP-совокупности?

И.П.: В принципе, логика построения всех ERP-совокупностей аналогична. Исходя из этого могу ответить на свежем примере – автоматизации управления транснациональной корпорацией Legrand. Был совершён кроме того несколько проект, а пара, для различных SBU (strategic business unit, стратегических бизнес-единиц – Executive.ru), плюс неспециализированная интеграция.

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

Ну и от количества вовлеченных ресурсов – как с отечественной стороны, так и со стороны клиента. Последнюю стадию доработок мы стараемся минимизировать – еще один довод в пользу Agile.

Движение внедрения контролируется начальником проекта и систематично освещается на протяжении заседаний представителями клиента, а также с топ-менеджментом.

Executive.ru: Назовите, прошу вас, главные характеристики ERP-совокупностей.

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

Иначе говоря увлекательна практическая целесообразность выбора конкретного IT-решения, и слагаемые полной цене владения.

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

Это именно то, чего нужно стараться всеми силами избегать.

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

Последним назову цена владения. Само собой разумеется, направляться ориентироваться на качества и разумное соотношение цены, а также помощи. И помнить о том, что «скупой платит два раза».

Executive.ru: Какие конкретно главные риски внедрения ERP? Какой самый главный риск, на ваш взор?

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

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

А.К.: По-моему, главный риск – неправильно определенные цели. Причем не цели проекта внедрения ERP, а цели бизнеса. Как раз исходя из этого «внезапно» исчезает энтузиазм.

На определенной глубине детализации клиент может осознать, что не возьмёт желаемый эффект в бизнесе – и тогда он выйдет из проекта, либо начнет его тормозить.

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

Executive.ru: Разумеется, приступая к внедрению ERP, и клиент, и поставщик совокупности нацелены на успех. И в случае если заблаговременно известны риски, то… наивно ожидать, что этого окажется достаточно для предотвращения неприятностей?

И.П.: Конечно. Не напрасно так как управление рисками выделяют в отдельный раздел управления проектами. Рискуя показаться очевидной, отмечу, что при планировании проекта принципиально важно выяснить до 10 самые вероятных рисков.

Не более! Все предугадать нереально. Любой клиент личен.

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

А.К.: Добавлю, что для предотвращения неприятностей принципиально важно обеспечить: однозначное распределение ответственности за конкретные работы; верное, однозначное разграничение работ, с исчисляемым результатом по каждой задаче; перечень работ должен быть изначально полон.

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

Executive.ru: Раз мы заговорили о неприятных вариантах – по каким показателям возможно выяснить, что внедрение ERP не просто «буксует», а совсем провалилось? И как предотвращать такие ситуации?

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

Как не допустить? сопоставление и Планирование замысел/факта на регулярной базе. В случае если сроки очередного этапа срываются, нужно устранить обстоятельство срыва и перестроить технологические ответы оставшихся этапов, дабы успеть в более сжатые сроки. Быть может, нужно будет пожертвовать чем-то из менее серьёзного функционала, отыскать какие-то другие методы.

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

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

И.П.: по поводу предотвращения – я уже упомянула, что принципиально важно «вскрыть» потребности клиента еще на стадии предварительных переговоров. Вправду ли он испытывает недостаток в ERP? Из-за чего?

Что он реально желает от совокупности? Готов ли он вкладываться не только деньгами, но и людскими ресурсами в ее внедрение? В случае если на эти вопросы взяты четкие ответы, то риск провала а также «пробуксовки» проекта пытается к нулю.

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

Executive.ru: Каких обеспечений клиенты должны потребовать у разработчиков? Адекватных, очевидно. Тот же вопрос вам, Инна – какие конкретно гарантии поставщики ERP-совокупностей готовы давать?

А.К.: Обеспечений качества. Готов дать согласие с Инной в том, что если не уложились в сроки либо бюджет из-за неучтенных ранее требований – это не хорошо, но тут вина не только исполнителя. А вот уровень качества, на мой взор, исполнитель не только может обеспечить, но и обязан. Причем, никакие «отмазки» по этому пункту не окажут помощь.

Исходя из этого при выборе поставщика IT-продукта и контролируют репутацию, наровне с экспертизой предметной области.

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

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

Executive.ru: Что разработчики желают и вправе потребовать у клиентов, кроме оплаты? Имеется некоторый «райдер», без исполнения которого приличная IT-компания не возьмется за проект?

И.П.: Вовлеченности в проект. Буду настойчива по донесению данной мысли, по причине того, что в противном случае качественное ответ делается полностью недостижимым. Со стороны клиента неизменно должна быть полная готовность к сотрудничеству: пояснениям, консультациям, интервью.

Без исполнения этих условий затевать проект не имеет ни мельчайшего смысла.

А.К.: Кроме оплаты? Предоплату. В случае если без шуток, согласен – готовность компании к внедрению нужна.

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

Executive.ru: Представьте, что ваш партнер по внедрению ERP совершенен. Наилучший поставщик! И вот вы совместно организуете примерно-показательное внедрение.

Как оно выглядит?

А.К.: Имеется экономическое обоснование, измеряемые цели проекта, функциональные требования и use-cases (формальное описание сотрудничеств между пользователями с полномочиями и разными ролями в IT-совокупности, примечание редакции). Возможности ERP без доработок покрывают 99% функциональных требований.

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

И без того ежедневно, а не только перед подписанием актов и выставлением квитанций.

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

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

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

Какие конкретно вопросы стороны обязательно должны задать друг другу

Что обязан узнать поставщик ERP-совокупности у клиента

Что обязан узнать клиент
у системы и-поставщика

1. Из-за чего вы сделали вывод, что вам нужна ERP-совокупность? Вправду ли вы нуждаетесь в ERP?

2. Из-за чего вы вычисляете, что вам нужна эта совокупность (в случае если указывается конкретная)?

3. Из-за чего обратились к нам?

4. Что реально вы желаете получить от совокупности?

5. Готовы ли вы вкладываться не только деньгами, но и людскими ресурсами в ее внедрение?

6. Каковы настоящие цели (не цели проекта внедрения ERP, а цели бизнеса)?

7. Каковы экономические ожидания от внедрения ERP?

1. Что именно вы внедряли?

2. Где, какой масштаб пользователей-и компаний заказчиков ваших IT-ответов?

3. В то время, когда? В случае если в далеком прошлом, имели возможность уйти те, кто добился этого успеха.

4. Какой у вас подход? Что выяснено в качестве рамок проекта?

5. Как контролируется движение внедрения ERP-совокупности?

6. Каковы функциональные возможности совокупности?

7. Каковы возможности ее развития, интеграции и поддержки?

8. Каковы характеристики, каковые воздействуют на возможность расширения функционала совокупности и повышение числа пользователей?

9. Какова цена владения совокупностью?

Главные параметры: время, цена, уровень качества. Они фиксируются документально.

Совершенно верно своевременно для России: практика применения ERP-совокупностей Альпина Паблишер 2010 Дмитрий Исаев, Николай Оладов, С. Питеркин SAP ERP: Построение действенной совокупности управления Альпина Паблишер 2008 Джек Коверт IT-менеджмент2609 12

Из-за чего разработка вебмагазина преобразовывается в муку?

IT-менеджмент4546 6

Шесть обстоятельств, по которым ваш IT-проект будет провален

"Письмо"


К прочтению:

spacer