Внедрение без обмана

Давно и безвозвратно канули в Лету те благословенные времена, когда заботы IT-менеджера сводились почти исключительно к установке и сопровождению серверных и клиентских операционных систем. Все чаще и чаще на информационную службу возлагается ответственность за автоматизацию бизнес-процессов. В круг ваших знакомых и любимых обязанностей активно вторгаются новые, - связанные со спецификой различных областей учета и управления. Впрочем, термин "вторжение" не популярен. Повсеместно используется его более мягкий синоним, означающий, если вдуматься, то же самое - ВНЕДРЕНИЕ.

Алексей Федосеев

Давно и безвозвратно канули в Лету те благословенные времена, когда заботы IT-менеджера сводились почти исключительно к установке и сопровождению серверных и клиентских операционных систем. Все чаще и чаще на информационную службу возлагается ответственность за автоматизацию бизнес-процессов. В круг ваших знакомых и любимых обязанностей активно вторгаются новые, - связанные со спецификой различных областей учета и управления. Впрочем, термин "вторжение" не популярен. Повсеместно используется его более мягкий синоним, означающий, если вдуматься, то же самое - ВНЕДРЕНИЕ.

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

1. Внедрение должно быть, действительно, необходимо.

Внедрение должно иметь бизнес и экономическое обоснование. Во-первых, речь может идти об автоматизации существующих бизнес-процессов, тогда его цель - повышение надежности и оперативности предоставления информации и выделение большего времени сотрудников на ее анализ, а не на обработку. Во-вторых, цель автоматизации может состоять в реорганизации бизнес-процессов. В любом случае ваше руководство должно быть готово к тому, что стоимость внедрения, как показывает наш опыт, будет составлять 1-2% от месячного оборота фирмы. (Разумеется, речь идет о комплексной автоматизации). Если же бизнес-цели не ясны, или руководство не считает адекватной приведенную выше цену, или бюджет вашего предприятия просто не выдержит рыночной цены внедрения - лучшее, что вы сможете сделать, это мягко спустить дело на тормозах. Ничего путного все равно не получится, а все проблемы свалят на вас.

2. Одно внедрение приравнивается к трем пожарам.

Да, головной боли у вас определенно прибавится. Но коль скоро необходимость внедрения объективна (см. п.1), сопротивляться ему - дело бесперспективное. Правильнее с самого начала занять в процессе свое достойное и важное место.

3. Внедрение не сводится к покупке коробки.

Любой софт требует сопровождения. Деловой особенно. Кто и как будет осуществлять все изменения законодательства и учета на вашем предприятии? Если же изначально ясно, что внедрение предполагает проект с составлением ТЗ, кодированием и проч., то имейте в виду, что:

4. Самостоятельное внедрение так же эффективно, как и самолечение.

"Минздрав не рекомендует".

Простых областей учета и управления - нет. На изучение и кодирование потребуются месяцы и годы работы. Ответственность - огромна. Результаты - призрачны. Вам это надо?

5. Вам нужны не контрагенты, а союзники.

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

6. Всякой коробке свое время.

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

7. Москва словам не верит, - требуйте результат и вы.

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

8. Ваша ответственность должна соответствовать вашим полномочиям.

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

9. За работу системы вам придется отвечать и через год, и через три.

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

10. Ваша позиция и авторитет будут зависеть от результатов внедрения.

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

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

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

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

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

А теперь, внимание - парадоксально, но в общем случае любое внедрение имеет фиксированное количество обязательных этапов. Можете называть этот парадокс правилом "ИНТАЛЕВ". Что это за этапы?

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

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

Хотя "ответов" - это громко сказано. Как правило, цели впервые ясно и четко формулируются как раз в результате этого этапа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С тем, как строить маршрут разобрались. Но (помните?) - важен маршрут и экипировка. Утверждаю, - роль экипировки в многотрудном деле внедрения играет документированность результатов (кстати, этимология понятий "экипировка" и "оформление" представляется близкой, - правда, я не лингвист).

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

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

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

Начать дискуссию