[Из песочницы] Эффективность внедрения информационных систем. Опыт практика
У меня есть многолетний опыт внедрения и последующего сопровождения информационных систем на различных предприятиях. Опыт, в большинстве случаев, был успешным –, но здесь я хочу побеседовать, в первую очередь, о причинах, ведущих к неудаче в этом деле, предостеречь вас от возможных ошибок. Я означу собственный метод внедрения, который я использовал неоднократно и который помогает избежать большинства из них.
Первая и самая главная причина провала: некорректно поставленная цель для информационной системы.
Это один из основных вопросов для любого проекта вообще. Заказчик зачастую выбирает цель, которая не имеет к информационной системе никакого отношения, или же зависит от нее незначительно. Примеры: увеличение продаж, занятие большей доли рынка, создание другой культуры управления предприятием и т. д. Но если компания производит товар, спрос на который падает — как тут поможет информационная система? Проблему здесь должно решать подразделение маркетинга. Если нужно изменить культуру предприятия — это вопрос управления персоналом и генерального директора. У некоторых, однако, теплится надежда, что стоит отдать деньги за информационную систему — и проблемы, связанные с организаций бизнеса, решатся сами собой. Обещания продавцов, «впаривающих» дорогие, иностранного производства, многократно проверенные и построенные на «лучших мировых бизнес-практиках» системы лишь укрепляют эту веру. Но на деле компания с неэффективным стилем управления останется неэффективной, только уже с информационной системой. Если на вашу продукцию упал спрос, он тоже не изменится никак. Правда, информационная система позволит вам быстро и точно подсчитать убытки, в том числе и от ее внедрения.
Корректно поставленная цель внедрения информационной системы — залог успеха этого внедрения. Правильны цели, связанные с обработкой информации: хранение, поиск данных, задачи, связанные с расчетами, группировкой, анализом. При внедрении системы все это требовать меньше времени. Помните, однако, что ускорение неудачных процессов приведет к еще более неудачному результату для компании, чем было бы без системы.
Вот один из недавних случаев на переговорах с заказчиком. Заказчик хочет сменить систему конфигурирования изделия, надеясь, что это упорядочит работу производства. С его слов, новая система должна предоставить только ограниченный выбор доступных опций изделий. Тогда производству и отделу согласования будет проще работать, появится набор стандартных решений. У заказчика, однако, уже есть конфигуратор. Сразу возник вопрос: зачем менять? Ответ потрясающий: другой конфигуратор «заставит нас работать правильно», создать необходимую документацию на изделие, изменить схемы обработки заказов и скорректировать культуру работы с заказчиком. Получается, менеджеры понимают, в чем проблема, но расписываются в собственном бессилии изменить ситуацию и перекладывают трудности по реорганизации бизнес-процессов на подразделение, которое за это не отвечает. Как правило, такой проект завершается крахом или затягивается на долгие годы.
Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.
Эффективные цели
Повторюсь — цели, которые я считаю эффективными при внедрении информационной системы, связаны с ускорением существующих бизнес-процессов или созданием новых для обработки данных. Не стоит перекладывать на информационную систему задачи других подразделений, особенно без права влиять на эти процессы.
Внедрение информационной системы позволяет запустить бизнес-процессы, которые прежде не имели права на существование из-за неприемлемых сроков выполнения. Более того, я считаю, что запуск новых бизнес-процессов — обязательное условие для успешного внедрения системы. Очевидно, если раньше мы использовали напильник для выполнения работ, а теперь у нас станок, это будет другой процесс. Если планирование было налажено плохо, станок, из-за своей производительности, принесет компании еще больший убыток.
Итак, с целями мы определились, теперь осталось правильно составить техническое задание.
Техническое задание
Это вторая по важности составляющая успеха при внедрении информационной системы. Напомню, эффективная цель — ускорение бизнес процессов, которых может быть еще не существует. Заказчик только в общих чертах понимает, что ему нужно. Хорошим вариантом считается уже на первых этапах работы составить подробное многостраничное ТЗ. Это работает, особенно для исполнителя по контракту. Заказчик все подписывает, не до конца понимая, что именно сделает исполнитель. А между тем, за каждое новое поле или форму, не записанные в ТЗ, исполнитель запросто попросит с заказчика еще денег. В итоге заказчик получит процесс с неполными или избыточными данными, хотя формально контракт был выполнен в точном соответствии с требованием. Заказчик будет недоволен и во второй раз к этому исполнителю не обратится.
Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то — не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите — «ну, вы же специалисты, должны были сами все знать заранее».
Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ — списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1–2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.
Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика — автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.
Следующим важным документом для успешного выполнения работ является план-график работ.
План-график работ
План-график — документ, содержащий план конкретных работ, в котором описаны действия, которые должны выполнить как заказчик, так и исполнитель. План-график нужен для оперативного контроля за работой обеих сторон. Как правило, в нем перечисляются все системы и подсистемы со своими процессами, документами, отчетами, которые будут разработаны и внедрены. К примеру: действия заказчика, связанные с организацией рабочих мест, прокладкой коммуникаций, обучением персонала и т.д. На каждом пункте плана-графика может быть проставлена цена и длительность, это дает возможность делать взаиморасчеты между исполнителем и заказчиком. Работы, конечно, могут идти параллельно. Хорошо использовать диаграммы Ганта или что-то аналогичное, но не обязательно.
Запуск системы в работу
Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50–70% процентах рабочих мест.
Персонал проходит обучение, для пользователей составляются краткие инструкции. Этот этап может длиться от нескольких минут до нескольких недель. Хорошо работают методы экстремального программирования, когда поступившие замечания от сотрудников исполнителя сразу устраняются квалифицированными разработчиками заказчика, желательно на месте у заказчика. Тем самым за одну, максимум две недели можно решить основную массу проблем, связанных с запуском и адаптацией системы. Без масштабного запуска с неукоснительным требованием руководства заказчика введение в эксплуатацию может затягиваться на долгие месяцы. Если нет жесткого требования руководства, люди будут работать по-старому. При любых нововведениях у людей лишь возникнет ощущение, что им кто-то мешает жить.
После этапа опытной эксплуатации сразу следует промышленная. Отличие между ними только в количестве замечаний, которые должны быть устранены, и в отсутствии критических проблем, при наличии которых эксплуатация становится невозможной.
В итоге мы получаем такие этапы запуска и внедрения системы:
- Тестирование с привлечением сотрудников заказчика на реальных примерах;
- Опытная эксплуатация с немедленным устраняем возникающих проблем;
- Промышленная эксплуатация.
Этот метод был проверен мной многократно на предприятиях различных масштабов. Сотрудники компании заказчика в некоторые моменты испытывают дискомфорт, как и сотрудники исполнителя. Но, к счастью, дискомфорт этот быстро сходит на нет, и предприятие переходит в планомерную работу при конструктивном подходе к решению возникающих задач.
Комментарии (5)
pan_KOST
18 августа 2016 в 12:39 (комментарий был изменён)
0↑
↓
Хорошо, хоть есть такие люди… Но интеграторы часто зарабатывают деньги только потому, что не сильно сопротивляются подходу заказчика — вы нам внедрите эту систему, а уж зачем мы сами разберёмся, при этом бизнес-процессы заказчика не меняются абсолютно.Возвращаясь к ИТ-скепитку в триаде люди-процессы-технологии, большинство видит только технологию, хотя часто сначала надо исправить процессы и внедрить их и под это выбирать технологию, а иногда, как и говорит автор, сначала поменять культуру компании…
Кстати, со стороны заказчика, хочу обратить внимание на серьёзное упущение со стороны интеграторов, следующих подходу «пришёл-сделал-ушёл» — ещё в начале внедрения системы должен быть явно проработаны последние два важных этапа Поддержка и Развитие.
Без них -система постепенно деградирует и цели в долгосрочной перспективе достигнуты не будут.В этом плане очень показателен подход Кайдзен vs Инновации
18 августа 2016 в 13:08
0↑
↓
Еще в стадии записать Смерть(она же вывод из эксплуатации).
А по развитию — хорошо себя чувствует тот, чья система успевает за его потребностями (ну отстает по минимуму). Жизнь меняется значительно быстрее, чем кажется. Но, к сожалению, некоторые «покупатели» видят софт как «купил и забыл».
А еще «Поддержка? — Сами разберемся!», «Доработки — Почему так дорого, четверть стоимости коробки за небольшой модуль!». Тут я больше о коробочном софте для малого бизнеса.
PS А графики честно не понял =)-
pan_KOST
18 августа 2016 в 13:15
0↑
↓
По поводу вывода их эксплуатации — да, согласен, это тоже часто вопрос.
Развитие — целиком и полностью согласен — и именно поэтому я и привёл графики с Кайдзен, т.к. этот подход как раз и пропагандирует постоянное улучшение.
Подробнее (в т.ч. и про графики =)) — Масааки Имаи — Кайдзен: Ключ к успеху японских компаний. Глава 2 — Совершенствовании на Востоке и Западе.18 августа 2016 в 14:12 (комментарий был изменён)
0↑
↓
Для меня вывод из эксплуатации как правило означает: клиент переходит с чего то на наш софт, необходимо вытащить оттуда все полезное. И вот некоторые производители софта подумали об этом и дали как минимум экспорт с минимальной гибкостью. А у некоторых все не очень.
Хотя вопрос конечно шире.
PS А про кайдзен я в курсе, графики для неподготовленного человека туманно идентичны (не подписаны оси, немного разный масштаб, чуть тут, чуть там). Без расшифровки не прокатит.
18 августа 2016 в 13:28
0↑
↓
Кстати, со стороны заказчика, хочу обратить внимание на серьёзное упущение со стороны интеграторов, следующих подходу «пришёл-сделал-ушёл» — ещё в начале внедрения системы должен быть явно проработаны последние два важных этапа Поддержка и Развитие.
Без них -система постепенно деградирует и цели в долгосрочной перспективе достигнуты не будут.
100% так. Нужно будет дополнить статью или написать другую «Поддержка и развитие» это важная тема тема.
