ИНТАЛЕВ: Внедрение без обмана II

Предыдущая часть

Алексей Федосеев,
Директор по информационным проектам
Консультационно-Внедренческой фирмы «ИНТАЛЕВ»

Статья была опубликована в Компьютер-Информ #17, 1999

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

Внедрение, или Как пойти туда, знаем куда

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

Постулат второй. Сложный маршрут, а простых внедрений не бывает, всегда состоит из этапов.
А теперь, внимание — парадоксально, но в общем случае любое внедрение имеет фиксированное количество обязательных этапов. Можете называть этот парадокс правилом «ИНТАЛЕВ». Что это за этапы?

Этап 1. Стратегическое планирование.

Топ-менеджеры компании должны сформулировать свои бизнес-цели и стратегию на ближайшие 1-2 года. Подчеркиваю, это задачи именно высшего руководства. Пока оно, нет, лучше они, не дадут своих ответов, всякая автоматизация бесполезна, ибо неясна ее цель. Так, нельзя идти просто в горы (именно поэтому умные туда не ходят). Между походом в Гималаи или в Карпаты есть, согласитесь, некоторая разница.
Хотя «ответов» — это громко сказано. Как правило, цели впервые ясно и четко формулируются как раз в результате этого этапа.

Этап 2. Формализация бизнес-процессов.  

После понимания задач в бизнесе можно переходить к следующему этапу — постановке задач на автоматизацию. Кратко, для топ-менеджеров должно быть понятно описано, — какие задачи будут автоматизированы и как. В ходе этапа составляется 5-15 схем движения информации (по одной на функциональную область — планирование продаж, закупка, хранение и т.д). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовки и IT-менеджер. В результате этого этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений фирмы. Таким образом, это, фактически, этап постановки задачи.

Важность этих двух этапов можно продемонстрировать следующим примером. Один из наших Заказчиков — крупное производственное предприятие, выбрало нас в качестве субподрядчика для разработки ТЗ и его кодирования. Все наши доводы насчет необходимости планирования и постановки задачи были отметены. Руководство было непреклонно и не хотело (или не хотели?) «тратить время и деньги», — сразу же ТЗ! Мы предупредили о высокой вероятности неуспеха такого подхода. Увы, руководство сразу же спустило весь процесс написания ТЗ на начальников отделов, которые, естественно, не представляли системно всех задач. Мы их также не могли знать, поскольку это был не наш бизнес, не наше предприятие. После скоропостижного утверждения ТЗ и его кодировки выяснилось, что добрая половина автоматизированных бизнес-процессов была просто не нужна, поскольку руководство решило изменить их схемы выполнения, в другой половине были обнаружены грубые промахи (например, вследствие неверного понимания учетной политики). В результате тысячи долларов и несколько месяцев работ были потрачены для Заказчика впустую, о вероятности чего мы и предупреждали.

Этап 3. Оптимизация бизнес-процессов.

Постановка задачи на автоматизацию. После завершения предыдущего этапа мы получаем формализованное представление тех целей, которые ставит руководство, и тех бизнес-процессов, которые должны привести к достижению этих целей. Обычно это ПЕРВОЕ системное и реальное представление. А значит, почти всегда неоптимальное.
Обычно в результате оптимизации происходит реорганизация либо структуры предприятия, либо бизнес-процессов — реструктуризация и реинжиниринг соответственно. Зачем это нужно? У одного из наших Заказчиков в результате оптимизации мы провели реорганизацию складского учета, приведшую к трехкратному уменьшению складских потерь (продукты были скоропортящиеся). В результате принятых решений (и только после него) можно корректно определить перечень бизнес-процессов, подлежащих автоматизации, и план работ по автоматизации.

Этап 4. Техническое задание.

Опираясь на утвержденную постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: «Что надо автоматизировать?», а ТЗ — «Как конкретно надо автоматизировать?». ТЗ составляется с IT-менеджерами и начальниками отделов — «собственниками бизнес-процессов». В нем детально описываются все объекты информационной системы, их поведение и т.д. И чем детальнее будет ТЗ, тем лучше. Не успокаивайтесь, если вам скажут, что «не надо это описывать, это и так понятно».

Документировать надо. В противном случае все кончается примерно так. В момент сдачи-приемки ваши предметные специалисты с возмущением говорят, что не примут работы, апеллируя это тем, что: «нам ГОВОРИЛИ, что это будет сделано так, а сделано по-другому». Возникает коллизия, для разрешения которой одно средство — ТЗ. Все туда дружно смотрят. Скорее всего, как там написано, так и сделано. Формально прав внедренец (какое ужасное слово!) И теперь выбор в его руках — делать уступку и переделывать (платно либо бесплатно), или нет. НЕ ОТДАВАЙТЕ СВОЙ ВЫБОР В ЧУЖИЕ РУКИ.

Этап 5. Кодирование.

После утверждения ТЗ можно приступать к кодированию. Это самый неинтересный этап. Внутреннее дело внедряющей организации.

Этап 6. Разработка должностных инструкций.

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

Этап 7. Обучение пользователей.

Совершенно необходимо. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это значит, что ваши сотрудники будут вынуждены работать по-новому. И проблема состоит не только в том, что их нужно известить о грядущих изменениях и научить работать в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Раньше это называлось — «учесть человеческий фактор».

Этап 8. Опытная эксплуатация.

Закодировано начинается опытная эксплуатация. Очень важный этап. Этап, на котором можно объективно оценить все сделанное ранее. Система начинает работать не на бумаге. Требуйте ее четкой и правильной работы.

Внедрение, или Как принести то, знаем что

С тем, как строить маршрут разобрались. Но (помните?) — важен маршрут и экипировка. Утверждаю, — роль экипировки в многотрудном деле внедрения играет документированность результатов (кстати, этимология понятий «экипировка» и «оформление» представляется близкой, — правда, я не лингвист).
Итак, есть сложная, но результативная последовательность этапов. Каждый этап должен быть задокументирован и утвержден Заказчиком. Первый документ этапа — план его выполнения. Второй — план-факт исполнения работ. Третий — собственно результат этапа — «Отчет о постановке задачи», «Схемы автоматизируемых бизнес-процессов», «Техническое задание», «Должностные инструкции».

У фирмы-внедренца (ой, опять новояз) должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? Внедренец готов работать по любой предложенной Заказчиком форме? — плохой внедренец. Нельзя плясать под дудку Заказчика, ведь он не профессионал. Только представьте — (не дай Бог) приходите вы к врачу, — а он вас спрашивает: «как будем лечиться?». То есть, нужен еще один документ. В начале каждого этапа Заказчик должен утвердить формат документа результата по этому этапу. Хорошо, если этот формат будет совпадать/коррелировать с общепринятыми — ГОСТы, IDEFы. Цель — предсказуемость результата.

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

Продолжение статьи

• Раздел "Системы автоматизации (ERP/MRPII, SCM, CSRM)"
• Другие статьи по системам автоматизации

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме