За последние десять лет мне довелось участвовать в добрых двух десятках внедрений программных продуктов (далее ПП). Основной урок, который я вынес из всех этих внедрений, это разница между проектом внедрения и процессом.
Давайте посмотрим на процесс внедрения ПП на макро-уровне. Нужно внедрить некий ПП и при этом уложиться в заданный бюджет (срок, стоимость, персонал). Так этот процесс видит руководство компании. На практике зачастую ПП внедряется с превышением бюджета, да и процент провальных проектов крайне высок.
Попробуем проанализировать основные ошибки, которые допускаются при внедрении ПП:
1. Битвы проигрываются за столом
Как показывает практика, внедрить любой ПП в любой компании невозможно. Априорно предполагаем, что ПП «внедряемый», т.е. соответствует ожиданиям бизнеса, продукт развивается, существует команда знакомая с ПП и готовая его внедрять, продукт можно адаптировать под потребности бизнеса и при этом такая адаптация не приведет к созданию нового ПП (т.е. останется возможность перехода на новую версии ПП за срок менее, чем предполагаемый срок внедрения текущего ПП). Если продукт не «внедряемый», но его уже купили и перед Вами стоит задача его внедрить, то лучше оповестить об этом руководство и, по возможности, не участвовать в подобном проекте.
2. Есть ли у вас план, мистер Фикс?
Внедрение начинается с планирования. План внедрению нужен для того, чтобы в любой момент времени знать на каком этапе находится внедрение ПП, сколько еще осталось до момента его запуска, что уже сделано и что еще предстоит сделать. Для составления первоначального плана внедрения лучше использовать специализированные инструменты такие как Microsoft Project или Project Workbench. Их основное преимущество по сравнению с Microsoft Excel, возможность задания связей между задачами (например, обучение не может начаться, до окончания фазы настройки и т.д.), автоматическое отслеживание выходных дней (правда Вам все равно придется помнить о локальных праздниках, сезонах отпусков и т.д.) и возможность сравнения предполагаемого плана внедрения и текущего (например, в Microsoft Project, есть возможность задать т.н. baseline, и по мере внесения изменений с ходом проекта в план, сравнивать его с baseline). Зачастую, на этапе планирования просто не возможно предусмотреть «подводные камни» и задачи, которые «подразумевал»бизнес и которые не были отображены в первоначальном плане внедрения. В любом случае, чем детальней план, тем больше вероятность того, что Ваш проект будет выполнен вовремя. Под термином «детальный план», я подразумеваю «разумную» степень детализации, т.е. с точностью до логически неделимой задачи (например, обучение пользователей, подготовка определенного отчета и т.д.). Обязательно сделайте запас в плане внедрения: помните, что мгновенное переключение сотрудников с одной задачи на другую невозможно. Есть и объективные факторы, которые следует заложить в план внедрения. Например, переезды между офисами, зависимость от внешних поставщиков (например техники или коммуникационного оборудования) и т.д. Наш обычный запас времени в проекте колеблется в диапазоне 10-30%.
3. Внедрение - процесс или проект?
В чем разница между проектом и процессом внедрения? Сколько раз нам доводилось слышать, что компания XYZ внедряет систему ABC уже третий год и уже совсем почти внедрила. Это процесс внедрения: известно что внедряют, известно где внедряют, известно (по крайней мере кому-то) зачем внедряют, но вот конца проекта все нет. Мне доводилось слышать про проекты, которые длятся более пяти лет, которые внедряет уже третья по счету ИТ команда и пр.
Проект, в отличие от процесса - является конечным, как сказали бы математики сходящимся. У него есть четкие временные рамки, бюджет и он нужен заказчику.
Зачем нужны процессы внедрений?
Насколько я знаю, они служат разным целям: например, увеличению стоимости компании. К примеру, Вы объявляете о начале внедрения продукта ABC, подписываете с фирмой поставщиком договор на приобретение лицензий и внедрение продукта на 1 млн.$. Часть этой суммы платится сразу (предположим 25%), оставшаяся часть поэтапно по ходу окончания проекта (например, ежеквартально). Что произошло с точки зрения стоимости компании в которой начат процесс внедрения ABC? Она подорожала. В идеале на 1 млн.$, а то и больше. Вы заплатили за начало внедрение 250тыс$, ваша компания подорожала на 1млн.$ - надо ее скорее продавать :), что мы и видели в банковской системе Украины на протяжении последних нескольких лет: как только банк объявляет о подписании договора о внедрении "Большой системы", можно ожидать новостей о его продаже. Если продать компанию сразу не удается, а платить за внедрение нужно, дорогостоющую команду внедренцев распускают и набирают новую "не хуже, но дешевле". Главное для руководства компании максимизировать разницу между увеличением стоимости комапнии и стоимостью внедрения.
Также я встречал процессы внедрений в представительствах компаний, которые выполняются "для галочки". Предположим в компании уже есть локальное ИТ решение. Оно не дорогое, оно работает и в принципе устраивает всех кроме (подставьте нужное: ИТ менеджмента, аудиторов, HR или еще кого-то) головной компании, так как оно не соответствует (подставьте нужное: IT policy, не сертифицировано согласно стандарту, не такое как у остальных представительств и т.д.). Из головной компании в конце концов "пропихивается" идея сделать ИТ решение "как у всех" и начинается "процесс".
И последний тип - внедрения, которые никому не нужны или которые явным образом саботируются сотрудниками компании, где происходит внедрение. Давным давно, когда я еще занимался 1С, достался мне проект внедрения бухгалтерии на одном из отечественных телеканалов. В бухгалтерии работала стайка бухгалтерш душ до 10, которые что-то бойко и долго считали в Excel-e. У каждой из них был свой участок работ (например, расчет зарплаты, начисление амортизации и т.д.), которым они занимались практически целый месяц. Неделе на второй внедрения стало понятно, что назревают проблемы: амортизация вместо 20 дней считалась минут за 40, зарплата с учетом всех самых зверских начислений-удержаний вписывалась дня в 3-4. После этого проект перешел в процесс. Сотрудницы, которые еще вчера бойко что-то вводили в 1С сегодня потеряли к проекту всякий интерес. Нашлось несколько десятков причин почему "программа плохая" и чем "Excel лучше". Они поняли, что с внедрением 1С в их отделе грядут сокращения. Быть сокращенным никто не хотел и по-этому начался откровенный саботаж проекта. Мой пример не единичный, не раз видел внедряемые решения, которые захотел (подставить нужное: директор, испольнительный, финансовый или еще какой директор), которые не приносили рядовым сотрудникам никаких "added values" (как это сказать по русски :), а наоборот добавляли им хлопот, а то и напрямую грозили потерей рабочего места. К слову на телеканале мы месяцев через много 1С таки внедрили, но работала она только на тех участках, где не грозилу увольнением персоналу.
4. Вместо заключения
Как мы видим, универсального решения удачного и быстрого завершния проекта внедрения нет. Но есть ряд признаков, которые дают нам возможность надеяться, что проект внедрения не превратится в его процесс: «внедряемость» и востребованость продукта, наличие продуманного бюджета и плана внедрения, заинтересованность менеджмента компании в успешном завершении проекта, наличие преимуществ для конечных пользователей (уменьшение рутинного труда, упрощение сложных процессов и т.д.).
Давайте посмотрим на процесс внедрения ПП на макро-уровне. Нужно внедрить некий ПП и при этом уложиться в заданный бюджет (срок, стоимость, персонал). Так этот процесс видит руководство компании. На практике зачастую ПП внедряется с превышением бюджета, да и процент провальных проектов крайне высок.
Попробуем проанализировать основные ошибки, которые допускаются при внедрении ПП:
1. Битвы проигрываются за столом
Как показывает практика, внедрить любой ПП в любой компании невозможно. Априорно предполагаем, что ПП «внедряемый», т.е. соответствует ожиданиям бизнеса, продукт развивается, существует команда знакомая с ПП и готовая его внедрять, продукт можно адаптировать под потребности бизнеса и при этом такая адаптация не приведет к созданию нового ПП (т.е. останется возможность перехода на новую версии ПП за срок менее, чем предполагаемый срок внедрения текущего ПП). Если продукт не «внедряемый», но его уже купили и перед Вами стоит задача его внедрить, то лучше оповестить об этом руководство и, по возможности, не участвовать в подобном проекте.
2. Есть ли у вас план, мистер Фикс?
Внедрение начинается с планирования. План внедрению нужен для того, чтобы в любой момент времени знать на каком этапе находится внедрение ПП, сколько еще осталось до момента его запуска, что уже сделано и что еще предстоит сделать. Для составления первоначального плана внедрения лучше использовать специализированные инструменты такие как Microsoft Project или Project Workbench. Их основное преимущество по сравнению с Microsoft Excel, возможность задания связей между задачами (например, обучение не может начаться, до окончания фазы настройки и т.д.), автоматическое отслеживание выходных дней (правда Вам все равно придется помнить о локальных праздниках, сезонах отпусков и т.д.) и возможность сравнения предполагаемого плана внедрения и текущего (например, в Microsoft Project, есть возможность задать т.н. baseline, и по мере внесения изменений с ходом проекта в план, сравнивать его с baseline). Зачастую, на этапе планирования просто не возможно предусмотреть «подводные камни» и задачи, которые «подразумевал»бизнес и которые не были отображены в первоначальном плане внедрения. В любом случае, чем детальней план, тем больше вероятность того, что Ваш проект будет выполнен вовремя. Под термином «детальный план», я подразумеваю «разумную» степень детализации, т.е. с точностью до логически неделимой задачи (например, обучение пользователей, подготовка определенного отчета и т.д.). Обязательно сделайте запас в плане внедрения: помните, что мгновенное переключение сотрудников с одной задачи на другую невозможно. Есть и объективные факторы, которые следует заложить в план внедрения. Например, переезды между офисами, зависимость от внешних поставщиков (например техники или коммуникационного оборудования) и т.д. Наш обычный запас времени в проекте колеблется в диапазоне 10-30%.
3. Внедрение - процесс или проект?
В чем разница между проектом и процессом внедрения? Сколько раз нам доводилось слышать, что компания XYZ внедряет систему ABC уже третий год и уже совсем почти внедрила. Это процесс внедрения: известно что внедряют, известно где внедряют, известно (по крайней мере кому-то) зачем внедряют, но вот конца проекта все нет. Мне доводилось слышать про проекты, которые длятся более пяти лет, которые внедряет уже третья по счету ИТ команда и пр.
Проект, в отличие от процесса - является конечным, как сказали бы математики сходящимся. У него есть четкие временные рамки, бюджет и он нужен заказчику.
Зачем нужны процессы внедрений?
Насколько я знаю, они служат разным целям: например, увеличению стоимости компании. К примеру, Вы объявляете о начале внедрения продукта ABC, подписываете с фирмой поставщиком договор на приобретение лицензий и внедрение продукта на 1 млн.$. Часть этой суммы платится сразу (предположим 25%), оставшаяся часть поэтапно по ходу окончания проекта (например, ежеквартально). Что произошло с точки зрения стоимости компании в которой начат процесс внедрения ABC? Она подорожала. В идеале на 1 млн.$, а то и больше. Вы заплатили за начало внедрение 250тыс$, ваша компания подорожала на 1млн.$ - надо ее скорее продавать :), что мы и видели в банковской системе Украины на протяжении последних нескольких лет: как только банк объявляет о подписании договора о внедрении "Большой системы", можно ожидать новостей о его продаже. Если продать компанию сразу не удается, а платить за внедрение нужно, дорогостоющую команду внедренцев распускают и набирают новую "не хуже, но дешевле". Главное для руководства компании максимизировать разницу между увеличением стоимости комапнии и стоимостью внедрения.
Также я встречал процессы внедрений в представительствах компаний, которые выполняются "для галочки". Предположим в компании уже есть локальное ИТ решение. Оно не дорогое, оно работает и в принципе устраивает всех кроме (подставьте нужное: ИТ менеджмента, аудиторов, HR или еще кого-то) головной компании, так как оно не соответствует (подставьте нужное: IT policy, не сертифицировано согласно стандарту, не такое как у остальных представительств и т.д.). Из головной компании в конце концов "пропихивается" идея сделать ИТ решение "как у всех" и начинается "процесс".
И последний тип - внедрения, которые никому не нужны или которые явным образом саботируются сотрудниками компании, где происходит внедрение. Давным давно, когда я еще занимался 1С, достался мне проект внедрения бухгалтерии на одном из отечественных телеканалов. В бухгалтерии работала стайка бухгалтерш душ до 10, которые что-то бойко и долго считали в Excel-e. У каждой из них был свой участок работ (например, расчет зарплаты, начисление амортизации и т.д.), которым они занимались практически целый месяц. Неделе на второй внедрения стало понятно, что назревают проблемы: амортизация вместо 20 дней считалась минут за 40, зарплата с учетом всех самых зверских начислений-удержаний вписывалась дня в 3-4. После этого проект перешел в процесс. Сотрудницы, которые еще вчера бойко что-то вводили в 1С сегодня потеряли к проекту всякий интерес. Нашлось несколько десятков причин почему "программа плохая" и чем "Excel лучше". Они поняли, что с внедрением 1С в их отделе грядут сокращения. Быть сокращенным никто не хотел и по-этому начался откровенный саботаж проекта. Мой пример не единичный, не раз видел внедряемые решения, которые захотел (подставить нужное: директор, испольнительный, финансовый или еще какой директор), которые не приносили рядовым сотрудникам никаких "added values" (как это сказать по русски :), а наоборот добавляли им хлопот, а то и напрямую грозили потерей рабочего места. К слову на телеканале мы месяцев через много 1С таки внедрили, но работала она только на тех участках, где не грозилу увольнением персоналу.
4. Вместо заключения
Как мы видим, универсального решения удачного и быстрого завершния проекта внедрения нет. Но есть ряд признаков, которые дают нам возможность надеяться, что проект внедрения не превратится в его процесс: «внедряемость» и востребованость продукта, наличие продуманного бюджета и плана внедрения, заинтересованность менеджмента компании в успешном завершении проекта, наличие преимуществ для конечных пользователей (уменьшение рутинного труда, упрощение сложных процессов и т.д.).
Комментариев нет:
Отправить комментарий