Идеальная ERP-система. Миф или реальность?
Итак, вы решили, что пора избавить компанию от хаоса, туманности бизнес-процессов и неопределенности в отчетности. Желание похвальное, но его реализация потребует огромных усилий. И если бы все зависело только от вас!..
Итак, вы решили, что пора избавить компанию от хаоса, туманности бизнес-процессов и неопределенности в отчетности. Желание похвальное, но его реализация потребует огромных усилий. И если бы все зависело только от вас!..
Врезка
Важно
Для того, чтобы внедрение ERP-системы не стало дополнительной головной болью, необходим ряд условий:
1. Воля, желание и упорство руководства компании. Проект весьма непростой и многое будет зависеть от ваших личных качеств, от умения довести начатое до логического завершения.
2. Четкое понимание того, что вы хотите получить в конечном счете, и зачем вам это нужно.
3. Поддержка со стороны сотрудников компании. Отсутствие саботажа.
4. Качественное техническое задание.
5. Качественный продукт, в рамках которого не придется разрабатывать «прописные истины» и «изобретать велосипед».
6. Хорошие, детальные инструкции по работе в системе и по ее настройке.
Шаг №1. Заручиться поддержкой топ-менеджеров
Прежде, чем приступать к проекту, определите уровень потенциальной внутренней поддержки его ключевыми сотрудниками компании (руководителями подразделений, топ-менеджерами). Соберите совещание, на котором объявите, что внедрение системы управления предприятием позволит бизнес-процессы сделать понятней и прозрачнее и перевести их в электронный вид; автоматизация документооборота позволит не только снизить количество ошибок при оформлении документов, но и на порядок ускорить процесс их оформления и т.д. Иными словами, ключевые сотрудники компании должны понять, какой эффект от внедрения получат именно они. Если после этого вы увидели энтузиазм в глазах большинства «топов», значит, проект имеет смысл начинать. Со скептиками придется поработать отдельно, потому что, как известно, ложка дегтя может испортить бочку меда. Если после индивидуальной беседы скептик остался скептиком, вам стоит подготовить себя к мысли, что с этим сотрудником, скорее всего, придется расстаться: он будет главным тормозом продвижения системы и, возможно, инициатором саботажа. Автоматизация бизнеса, так или иначе, ведет к его прозрачности. Почему некоторым сотрудникам не хочется прозрачности, я думаю, никому объяснять не надо.
Шаг №2. Осознанный выбор. Не отпустить проект в «никуда»
Поддержкой «топов» вы заручились, появилась уверенность в успехе. Что дальше?
Классическая ошибка, которую допускают почти все – делегирование поиска подходящей системы одному из сотрудников, который не найдет ничего лучше, кроме как на одном из интернет-форумов сообщить что «наша компания собирается внедрить ERP-систему» и т.д. Все подобные обращения заканчиваются одинаково – вас просто заваливают бесконечными обещаниями «все сделать недорого, в сжатые сроки и качественно». Причем, в большинстве случаев сообщения на форумах от потенциальных «жертв» не носят сколько-нибудь ясных очертаний и содержат в себе просто некий набор фраз типа: «хотели бы автоматизировать управленческий учет, бизнес-процессы и т.д.», которые в реальности для исполнителя не значат ровным счетом ни-че-го. Однако эти самые исполнители уже готовы выполнить ваш проект, как говорится, не глядя.
Следующая ошибка – так называемое «экспресс-обследование» от компаний, предложивших вам свои решения. Полнейшая чушь, не имеющая перед собой никаких других целей, кроме как «втереться в доверие к ключевым сотрудникам», «подзаработать хоть на этом», «главное ввязаться, а там разберемся» или просто «установить контакт». Никаких внятных результатов, как правило, экспресс-обследование не дает, кроме «мычания» со стороны обследующих и слабых намеков, что бизнес-процессы оказались запутанными и потребуется много усилий для их автоматизации. То есть ваших денег. Кроме того, пяток таких обследований только вызовет недовольство со стороны сотрудников компании, потому что придется отвечать на одни и те же вопросы типа: «покажите, как у вас сейчас все работает».
В результате этих ошибок проект серьезно рискует уйти в «никуда». У вас в компании постоянно будут находиться какие-то люди, задавать одни и те же вопросы и отнимать время у ваших сотрудников. Это может только вызвать дополнительное раздражение.
Вам придется самостоятельно отобрать потенциальных исполнителей проекта и с каждым встретиться. Да, и выбор тоже предстоит сделать самостоятельно. Выбор не простой. В ближайших статьях я планирую дать конкретные практические советы, которые позволят вам избежать ошибок при выборе и решения и консультантов по его внедрению.
Шаг №3. Разработать техническое задание
Это ключевой этап проекта. Именно на данном этапе вы должны однозначно сформулировать требования к будущей системе, причем не только тезисно, а в виде масштабного документа, полностью отвечающего на вопросы «кто», «что», «когда», «зачем». Причем, в этом документе все должно быть ясно не только вам, но и будущему исполнителю. И у разработчиков исполнителя не должно возникать слишком много вопросов по этому документу. Я неоднократно в своей практике встречал проекты, когда в техническом задании все было понятно только тому, кто его написал. Или в ТЗ прописывались только общие термины и тезисы, интерпретировать которые можно как угодно.
Четких стандартов разработки технических заданий для внедрения ERP-систем на сегодняшний день не существует. Да, конечно, некие ГОСТы есть. Но они не отвечают современным требованиям и по большей части регламентируют оформление, нежели содержание.
Врезка
Важно
Техническое задание должно четко показывать:
1. Как движутся бизнес процессы. Для их описания используются разные методы и стандарты, но в целом в схеме должно быть ясно, как движется процесс, что зачем следует, кто выполняет то или иное действие (функцию), когда и что должно быть на входе и выходе этого действия.
2. Роли. В схеме бизнес-процессов должно быть ясно, какие должны в системе существовать функциональные роли. Эти роли необходимо встроить в схему так, чтобы не возникало вопросов, кто и за что отвечает, кто и что делает. В дальнейшем эти функциональные роли должны быть связаны со штатной структурой компании. Таким образом станет понятно, кто именно в компании чем должен заниматься.
3. Таблицы. В техническом задании должны быть полностью описаны все информационные таблицы проекта. Каждая таблица (будь то справочник или список документов) должна быть определена с точки зрения ответственной роли. Всем должно быть понятно, кто отвечает за наполнение той или иной таблицы (справочника). Для каждой таблицы должен быть определен список полей и их форматов данных и источников данных. Вряд ли вы хотите оказаться в неприятной ситуации, когда разработчики будут вам предлагать заполнить какое-то поле вручную, в то время как вы считаете, что оно должно заполняться автоматически из определенного справочника.
4. Отчетность. Она должна быть описана максимально детально. Именно эта часть проекта может оказаться камнем преткновения, когда выяснится, что реализация того или иного отчета приведет к существенному увеличению объема работ, и, как следствие, бюджета.
Качественное техническое задание – это серьезный объем работ, который может занимать несколько месяцев. В ТЗ должно быть описано не столько «как есть», сколько «как надо». Значит, разработкой должен руководить опытный консультант, понимающий принципы организации правильных бизнес-процессов и разбирающийся, по каким законам вообще «живет» бизнес. Но это не означает, что к вам придут «волшебники», которые сами все расскажут. В разработке ТЗ заказчик должен участвовать самым непосредственным образом, причем заказчик из числа первых лиц компании. Техническое задание – это закон, по которому ваш бизнес будет жить в дальнейшем. Именно поэтому данный вопрос не стоит переадресовывать нижестоящим сотрудникам, большинство из которых не видят картину бизнеса в целом. Если за разные части ТЗ будут отвечать разные сотрудники, вы рискуете, в конце концов, получить совершенно разнородные части, срастить которые не представляется возможным.
Врезка
Важно
Отвечать со стороны заказчика за разработку ТЗ должен сотрудник, который:
• имеет полномочия формировать «правила игры»;
• понимает, как работает весь бизнес в целом;
• является положительным участником проекта, а не потенциальным саботажником.
С тем, как разрабатывать ТЗ, вроде бы все ясно. Но вот кто его должен разрабатывать – понятно далеко не всем.
Очевидно, что это должен быть опытный специалист, разрабатывавший подобные проекты неоднократно. Попросите предоставить вам примеры или фрагменты технических заданий. Попробуйте разобраться, что там написано. Если принцип понятен, значит, есть шанс все выполнить успешно. Поинтересуйтесь, какие решения внедрялись на базе этих ТЗ.
В идеале, за разработку технического задания должен отвечать будущий поставщик решения, тот, кто будет претворять в жизнь это ТЗ, то есть реализовывать на его основе систему управления предприятием. В противном случае вы рискуете попасть в ситуацию, когда компания, реализующая техническое задание в виде ERP-системы, будет «тыкать пальцем» на разработчика ТЗ и наоборот. Таким, образом, мы плавно подошли к главному вопросу – выбору решения.
Шаг №4. Выбор системы и консультантов. Быть или не быть.
Хочу отметить, что ошибки на предыдущих шагах поправимы. Ошибка на этом шаге гарантировано приведет проект к провалу. Будьте внимательны.
Расскажу о моем реальном опыте.
Одного моего знакомого пригласили на позицию исполнительного директора в некую торговую компанию. К тому времени уже в течение полугода в компании предпринимались попытки начать (не внедрить, а именно начать) автоматизацию предприятия усилиями компании X. Для начала мой коллега посмотрел на текущее состояние дел, и оно оказалось плачевным. Руководство нервничает — на презентации было обещано, что все будет замечательно, но вот прошло уже полгода, а ничего так и не появилось. Проект уже шел (вернее, представители компании X делали концептуальный проект, суть которого была понятна только тем, кто его делал), и деньги платились. Мой знакомый рассказал об этой ситуации, и мне стало интересно, почему так происходит. Я решил сам разобраться в ситуации и для начала заказал презентацию этого ERP-решения, обратившись в компанию X.
По окончании презентации меня больше возмутило не то, что этот продукт практически ничего не может, а то, с какой наглостью меня пытались обмануть, надеясь, по-видимому, на мою «чайниковость» и на то, что я не полезу в детали. Фактически мне просто пытались пустить пыль в глаза и завуалировать отсутствие элементарной функциональности какими-то «признаками», на которые, по мнению разработчика, обычный клиент наверняка «клюнет», а в детали он все равно не полезет. Ну а потом, когда начнется внедрение, кто там что вспомнит? Видимо, расчет был на это. Разоблачать горе-разработчиков приходилось с большими усилиями, поскольку врали мне постоянно и настойчиво. После того, как вскрывался один обман, консультанты подсовывали мне новую ложь, и снова приходилось разбираться в деталях, чтобы вскрыть неправду. «Через тернии к звездам», так сказать.
Общая продолжительность презентации составила около 12 часов, поскольку я вникал в мельчайшие детали (к сожалению, так редко делает большинство реальных клиентов). В конце концов я уже мог сказать с уверенностью, что о функциональных возможностях этой ERP-системы знаю все.
Врезка
Важно
Для того, чтобы внедрение ERP-системы не стало дополнительной головной болью, необходим ряд условий:
1. Воля, желание и упорство руководства компании. Проект весьма непростой и многое будет зависеть от ваших личных качеств, от умения довести начатое до логического завершения.
2. Четкое понимание того, что вы хотите получить в конечном счете, и зачем вам это нужно.
3. Поддержка со стороны сотрудников компании. Отсутствие саботажа.
4. Качественное техническое задание.
5. Качественный продукт, в рамках которого не придется разрабатывать «прописные истины» и «изобретать велосипед».
6. Хорошие, детальные инструкции по работе в системе и по ее настройке.
Шаг №1. Заручиться поддержкой топ-менеджеров
Прежде, чем приступать к проекту, определите уровень потенциальной внутренней поддержки его ключевыми сотрудниками компании (руководителями подразделений, топ-менеджерами). Соберите совещание, на котором объявите, что внедрение системы управления предприятием позволит бизнес-процессы сделать понятней и прозрачнее и перевести их в электронный вид; автоматизация документооборота позволит не только снизить количество ошибок при оформлении документов, но и на порядок ускорить процесс их оформления и т.д. Иными словами, ключевые сотрудники компании должны понять, какой эффект от внедрения получат именно они. Если после этого вы увидели энтузиазм в глазах большинства «топов», значит, проект имеет смысл начинать. Со скептиками придется поработать отдельно, потому что, как известно, ложка дегтя может испортить бочку меда. Если после индивидуальной беседы скептик остался скептиком, вам стоит подготовить себя к мысли, что с этим сотрудником, скорее всего, придется расстаться: он будет главным тормозом продвижения системы и, возможно, инициатором саботажа. Автоматизация бизнеса, так или иначе, ведет к его прозрачности. Почему некоторым сотрудникам не хочется прозрачности, я думаю, никому объяснять не надо.
Шаг №2. Осознанный выбор. Не отпустить проект в «никуда»
Поддержкой «топов» вы заручились, появилась уверенность в успехе. Что дальше?
Классическая ошибка, которую допускают почти все – делегирование поиска подходящей системы одному из сотрудников, который не найдет ничего лучше, кроме как на одном из интернет-форумов сообщить что «наша компания собирается внедрить ERP-систему» и т.д. Все подобные обращения заканчиваются одинаково – вас просто заваливают бесконечными обещаниями «все сделать недорого, в сжатые сроки и качественно». Причем, в большинстве случаев сообщения на форумах от потенциальных «жертв» не носят сколько-нибудь ясных очертаний и содержат в себе просто некий набор фраз типа: «хотели бы автоматизировать управленческий учет, бизнес-процессы и т.д.», которые в реальности для исполнителя не значат ровным счетом ни-че-го. Однако эти самые исполнители уже готовы выполнить ваш проект, как говорится, не глядя.
Следующая ошибка – так называемое «экспресс-обследование» от компаний, предложивших вам свои решения. Полнейшая чушь, не имеющая перед собой никаких других целей, кроме как «втереться в доверие к ключевым сотрудникам», «подзаработать хоть на этом», «главное ввязаться, а там разберемся» или просто «установить контакт». Никаких внятных результатов, как правило, экспресс-обследование не дает, кроме «мычания» со стороны обследующих и слабых намеков, что бизнес-процессы оказались запутанными и потребуется много усилий для их автоматизации. То есть ваших денег. Кроме того, пяток таких обследований только вызовет недовольство со стороны сотрудников компании, потому что придется отвечать на одни и те же вопросы типа: «покажите, как у вас сейчас все работает».
В результате этих ошибок проект серьезно рискует уйти в «никуда». У вас в компании постоянно будут находиться какие-то люди, задавать одни и те же вопросы и отнимать время у ваших сотрудников. Это может только вызвать дополнительное раздражение.
Вам придется самостоятельно отобрать потенциальных исполнителей проекта и с каждым встретиться. Да, и выбор тоже предстоит сделать самостоятельно. Выбор не простой. В ближайших статьях я планирую дать конкретные практические советы, которые позволят вам избежать ошибок при выборе и решения и консультантов по его внедрению.
Шаг №3. Разработать техническое задание
Это ключевой этап проекта. Именно на данном этапе вы должны однозначно сформулировать требования к будущей системе, причем не только тезисно, а в виде масштабного документа, полностью отвечающего на вопросы «кто», «что», «когда», «зачем». Причем, в этом документе все должно быть ясно не только вам, но и будущему исполнителю. И у разработчиков исполнителя не должно возникать слишком много вопросов по этому документу. Я неоднократно в своей практике встречал проекты, когда в техническом задании все было понятно только тому, кто его написал. Или в ТЗ прописывались только общие термины и тезисы, интерпретировать которые можно как угодно.
Четких стандартов разработки технических заданий для внедрения ERP-систем на сегодняшний день не существует. Да, конечно, некие ГОСТы есть. Но они не отвечают современным требованиям и по большей части регламентируют оформление, нежели содержание.
Врезка
Важно
Техническое задание должно четко показывать:
1. Как движутся бизнес процессы. Для их описания используются разные методы и стандарты, но в целом в схеме должно быть ясно, как движется процесс, что зачем следует, кто выполняет то или иное действие (функцию), когда и что должно быть на входе и выходе этого действия.
2. Роли. В схеме бизнес-процессов должно быть ясно, какие должны в системе существовать функциональные роли. Эти роли необходимо встроить в схему так, чтобы не возникало вопросов, кто и за что отвечает, кто и что делает. В дальнейшем эти функциональные роли должны быть связаны со штатной структурой компании. Таким образом станет понятно, кто именно в компании чем должен заниматься.
3. Таблицы. В техническом задании должны быть полностью описаны все информационные таблицы проекта. Каждая таблица (будь то справочник или список документов) должна быть определена с точки зрения ответственной роли. Всем должно быть понятно, кто отвечает за наполнение той или иной таблицы (справочника). Для каждой таблицы должен быть определен список полей и их форматов данных и источников данных. Вряд ли вы хотите оказаться в неприятной ситуации, когда разработчики будут вам предлагать заполнить какое-то поле вручную, в то время как вы считаете, что оно должно заполняться автоматически из определенного справочника.
4. Отчетность. Она должна быть описана максимально детально. Именно эта часть проекта может оказаться камнем преткновения, когда выяснится, что реализация того или иного отчета приведет к существенному увеличению объема работ, и, как следствие, бюджета.
Качественное техническое задание – это серьезный объем работ, который может занимать несколько месяцев. В ТЗ должно быть описано не столько «как есть», сколько «как надо». Значит, разработкой должен руководить опытный консультант, понимающий принципы организации правильных бизнес-процессов и разбирающийся, по каким законам вообще «живет» бизнес. Но это не означает, что к вам придут «волшебники», которые сами все расскажут. В разработке ТЗ заказчик должен участвовать самым непосредственным образом, причем заказчик из числа первых лиц компании. Техническое задание – это закон, по которому ваш бизнес будет жить в дальнейшем. Именно поэтому данный вопрос не стоит переадресовывать нижестоящим сотрудникам, большинство из которых не видят картину бизнеса в целом. Если за разные части ТЗ будут отвечать разные сотрудники, вы рискуете, в конце концов, получить совершенно разнородные части, срастить которые не представляется возможным.
Врезка
Важно
Отвечать со стороны заказчика за разработку ТЗ должен сотрудник, который:
• имеет полномочия формировать «правила игры»;
• понимает, как работает весь бизнес в целом;
• является положительным участником проекта, а не потенциальным саботажником.
С тем, как разрабатывать ТЗ, вроде бы все ясно. Но вот кто его должен разрабатывать – понятно далеко не всем.
Очевидно, что это должен быть опытный специалист, разрабатывавший подобные проекты неоднократно. Попросите предоставить вам примеры или фрагменты технических заданий. Попробуйте разобраться, что там написано. Если принцип понятен, значит, есть шанс все выполнить успешно. Поинтересуйтесь, какие решения внедрялись на базе этих ТЗ.
В идеале, за разработку технического задания должен отвечать будущий поставщик решения, тот, кто будет претворять в жизнь это ТЗ, то есть реализовывать на его основе систему управления предприятием. В противном случае вы рискуете попасть в ситуацию, когда компания, реализующая техническое задание в виде ERP-системы, будет «тыкать пальцем» на разработчика ТЗ и наоборот. Таким, образом, мы плавно подошли к главному вопросу – выбору решения.
Шаг №4. Выбор системы и консультантов. Быть или не быть.
Хочу отметить, что ошибки на предыдущих шагах поправимы. Ошибка на этом шаге гарантировано приведет проект к провалу. Будьте внимательны.
Расскажу о моем реальном опыте.
Одного моего знакомого пригласили на позицию исполнительного директора в некую торговую компанию. К тому времени уже в течение полугода в компании предпринимались попытки начать (не внедрить, а именно начать) автоматизацию предприятия усилиями компании X. Для начала мой коллега посмотрел на текущее состояние дел, и оно оказалось плачевным. Руководство нервничает — на презентации было обещано, что все будет замечательно, но вот прошло уже полгода, а ничего так и не появилось. Проект уже шел (вернее, представители компании X делали концептуальный проект, суть которого была понятна только тем, кто его делал), и деньги платились. Мой знакомый рассказал об этой ситуации, и мне стало интересно, почему так происходит. Я решил сам разобраться в ситуации и для начала заказал презентацию этого ERP-решения, обратившись в компанию X.
По окончании презентации меня больше возмутило не то, что этот продукт практически ничего не может, а то, с какой наглостью меня пытались обмануть, надеясь, по-видимому, на мою «чайниковость» и на то, что я не полезу в детали. Фактически мне просто пытались пустить пыль в глаза и завуалировать отсутствие элементарной функциональности какими-то «признаками», на которые, по мнению разработчика, обычный клиент наверняка «клюнет», а в детали он все равно не полезет. Ну а потом, когда начнется внедрение, кто там что вспомнит? Видимо, расчет был на это. Разоблачать горе-разработчиков приходилось с большими усилиями, поскольку врали мне постоянно и настойчиво. После того, как вскрывался один обман, консультанты подсовывали мне новую ложь, и снова приходилось разбираться в деталях, чтобы вскрыть неправду. «Через тернии к звездам», так сказать.
Общая продолжительность презентации составила около 12 часов, поскольку я вникал в мельчайшие детали (к сожалению, так редко делает большинство реальных клиентов). В конце концов я уже мог сказать с уверенностью, что о функциональных возможностях этой ERP-системы знаю все.
***
Что представлял собой «триллер» под названием «Проведение презентации очень известной ERP-системы», я расскажу в одной из ближайших статей, где подробно поведаю, как именно я разбирался во всех тонкостях, как приходилось вскрывать ложь консультантов и выявлять отсутствие фундаментальных возможностей у презентуемого решения. Продолжение следует…
Александр Попов, бизнес-консультант AVA Systems
Опубликовано 07.12.2009