Сложный маршрут, а простых внедрений не бывает, всегда состоит из этапов.
А теперь, внимание – парадоксально, но в общем случае любое внедрение имеет фиксированное количество обязательных этапов.
Что это за этапы:
1. Этап 1. Стратегическое планирование. Топ-менеджеры компании должны сформулировать свои бизнес-цели и стратегию на ближайшие 1-2 года. Подчеркиваю, это задачи именно высшего руководства. Пока оно, нет, лучше они не дадут своих ответов, всякая автоматизация бесполезна, ибо неясна её цель. Так, нельзя идти просто в горы (именно поэтому умные туда не ходят). Между походом в Гималаи или в Карпаты есть, согласитесь, некоторая разница. Хотя “ответов” – это громко сказано. Как правило, цели впервые ясно и четко формулируются как раз в результате этого этапа.
2. Этап 2. Организационное проектирование. После понимания задач в бизнесе можно переходить к следующему этапу – постановке задач на автоматизацию. Кратко, понятно для топ-менеджеров должно быть описано – какие задачи будут автоматизированы и как. В ходе этапа составляется 5-15 схем движения информации (по одной на функциональную область – планирование продаж, закупка, хранение и т.д.). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовке и IT-менеджер. В результате этого этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений фирмы. Таким образом, это, фактически, этап постановки задачи. Важность этих двух этапов можно продемонстрировать следующим примером. Один из наших Заказчиков – крупное производственное предприятие, выбрало нас в качестве субподрядчика для разработки ТЗ и его кодирования. Все наши доводы насчёт необходимости планирования и постановки задачи были отметены. Руководство было непреклонно и не хотело (или не хотели?) “тратить время и деньги”, - сразу же ТЗ! Мы предупредили о высокой вероятности неуспешности такого подхода. Увы, руководство сразу же спустило весь процесс написание ТЗ на начальников отделов, которые, естественно, не представляли системно всех задач. Мы их также не могли знать, поскольку это был не наш бизнес, не наше предприятие. После скоропостижного утверждения ТЗ и его кодировки выяснилось, что добрая половина автоматизированных бизнес-процессов была просто не нужна, поскольку руководство решило изменить их схемы выполнения, в другой половине были обнаружены грубые промахи (например, вследствие неверного понимания учётной политики). В результате тысячи долларов и несколько месяцев работ были потрачены для Заказчика впустую, о вероятности чего мы и предупреждали.
3. Этап 3. Оптимизация бизнес-процессов. Постановка задачи на автоматизацию. После завершения предыдущего этапа мы получаем формализованное представление тех целей, которые ставит руководство и тех бизнес-процессов, которые должны привести к достижению этих целей. Обычно это ПЕРВОЕ системное и реальное представление. А значит, почти всегда неоптимальное. Обычно в результате оптимизации происходит реорганизация либо структуры предприятия либо бизнес-процессов – реструктуризация и реинжиниринг соответственно. Зачем это нужно? У одного из наших Заказчиков в результате оптимизации мы провели реорганизацию складского учета, приведшую к трехкратному уменьшению складских потерь (продукты были скоропортящиеся). В результате принятых решений (и только после него) можно корректно определить перечень бизнес-процессов, подлежащих автоматизации и план работ по автоматизации.
4. Этап 4. Техническое задание. Опираясь на утверждённую постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: "Что надо автоматизировать?", а ТЗ – "Как конкретно надо автоматизировать?". ТЗ составляется с IT-менеджерами и начальниками отделов – “собственниками бизнес-процессов". В нём детально описываются все объекты информационной системы, их поведение и т.д. И чем детальнее будет ТЗ, тем лучше. Не успокаивайтесь, если Вам скажут, что "не надо это описывать, это и так понятно". Документировать надо. В противном случае все кончается примерно так. В момент сдачи-приёмки Ваши предметные специалисты, с возмущением говорят, что не примут работы, поскольку-де: "нам ГОВОРИЛИ, что это будет сделано так, а сделано по-другому". Возникает коллизия, для разрешения которой одно средство – ТЗ. Все туда дружно смотрят. Скорее всего, как там написано, так и сделано. Формально прав внедренец (какое ужасное слово! Неужели, по-русски?). И теперь выбор в его руках – делать уступку и переделывать (платно либо бесплатно), или нет. Не отдавайте свой выбор в чужие руки.
Задавайте вопросы нашему консультанту, он ждет вас внизу экрана и всегда онлайн специально для Вас. Не стесняемся, мы работаем совершенно бесплатно!!!
Также оказываем консультации по телефону: 8 (800) 600-76-83, звонок по России бесплатный!
5. Этап 5. Кодирование. После утверждения ТЗ можно приступать к кодированию. Это самый неинтересный этап. Внутреннее дело внедряющей организации.
6. Этап 6. Разработка должностных инструкций. На самом деле, этап 5 и этап 6 не обязательно последовательны. То есть, даже наоборот – лучше, чтобы они были параллельны. Их задача – подготовка этапа опытной эксплуатации - необходимо обучить пользователей работе с системой (а иногда и с ПК) и выдать им должностные инструкции. Без этого созданная система пропадёт, как бы хороша она не была Бывают Заказчики, пытающиеся сэкономить на этом этапе. Все та же псевдоэкономия времени и денег. Печально вздыхаем, – как правило, на этапе опытной эксплуатации они сами попросят сделать должностные инструкции. В итоге теряется время.
7. Этап 7. Обучение пользователей. Совершенно необходимо. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это значит, что Ваши сотрудники будут вынeждены работать по-новому. И проблема не только в том, что их нужно поставить в известность о грядущих изменениях и научить работе в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Раньше это называлось – “учесть человеческий фактор”.
8. Этап 8. Опытная эксплуатация. Закодировано, начинается опытная эксплуатация. Очень важный этап. Этап, на котором можно объективно оценить все сделанное ранее. Система начинает работать не на бумаге. Требуйте ее чёткой и правильной работы.
С тем, как строить маршрут разобрались. Но помните? - важен маршрут и экипировка. Утверждаю – роль экипировки в многотрудном деле внедрения играет документированность результатов (кстати, этимология понятий “экипировка” и “оформление” представляется близкой, - правда, я не лингвист).
Итак, есть сложная, но результативная последовательность этапов. Каждый этап должен быть задокументирован и утверждён Заказчиком. Первый документ этапа – план его выполнения. Второй – план-факт исполнения работ. Третий – собственно результат этапа – "Отчёт о постановке задачи", "Схемы автоматизируемых бизнес-процессов", "Техническое задание", "Должностные инструкции".
У фирмы-внедренца (ой, опять новояз) должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? внедренец готов работать по любой предложенной Заказчиком форме? – плохой внедренец. Нельзя плясать под дудку Заказчика, ведь он не профессионал. Только представьте – (не дай Бог)приходите Вы к врачу – а он Вас спрашивает: “как будем лечиться?”.
То есть, нужен ещё один документ – в начале каждого этапа Заказчик должен утвердить формат документа результата по этому этапу. Хорошо, если они этот формат будет совпадать/коррелировать с общепринятыми – ГОСТы, IDEFы. Цель – предсказуемость результата.
Таким образом, только ознакомившись с форматами документов, сопровождающих работу внедряющей фирмы, не потратив не единого у.е., Вы сможете оценивать потенциальных внедренцев именно по качеству работ, а не по субъективным оценкам.
Опасно опираться на мнение знакомого главного бухгалтера, что вот-де их автоматизировала фирма, и результат очень хороший. Часто результатом для главного бухгалтера будет увеличение его авторитета, влияния, количества подчинённых, что вряд ли совпадает с оценкой результата внедрения для фирмы в целом.
И наоборот, если Вам говорят, что кто-то недоволен результатом внедрения, то это может означать обратное. Например, вряд ли результатом проекта по автоматизации крупной фирмы будет доволен уволенный (ставший лишним) восемнадцатый бухгалтер или менеджер по продажам, отрицательные результаты продаж которого теперь стали прозрачны руководству.
Одной из проблем маленьких деревень в давние времена был высокий процент детей рождающихся с генетическими отклонениями. Причина этого крылась в том, что муж и жена из-за того, что людей в деревнях мало, часто могли приходиться друг другу родственниками.
Вопрос: Какое изобретение конца 19 века резко снизило процент детей рождающихся с генетическими отклонениями в сельской местности?
Статью подготовил категорийный менеджер по работе с ключевыми клиентами Умберг Эмиль Дмитриевич. 
