– Управленческий учет, документооборот, управление по целям и KPI, КСУП, CRM, ERP, MES – далеко не полный список систем управления, автоматизация которых при грамотном подходе дает существенный экономический эффект.
Но всегда ли? Вот самые распространенные способы потерять деньги на автоматизации.
«Нету ТЗ – давай, до свиданья!»
Меня до сих пор удивляет каждый новый случай проекта автоматизации управления, в котором нет формализованных требований. Оправдания у компаний, которые ищут подрядчика под такой проект, могут быть разные: у нас нет времени на бумажки, тут все просто, мы наняли профессионалов...
При этом ситуация не столь однозначна, как кажется.
«Нету ТЗ – давай, до свиданья!» – эта фраза облетела Интернет несколько лет назад. Профессионалы из самых разных областей (дизайнеры, программисты, консультанты) лайкали картинку со словами: «Знаешь, где реальное дело начинается? Только там, где ТЗ появляется». Послание понятно: заказчики, приходите к профессионалам с готовым техническим заданием. Но только где вы найдете клиента, владеющего функционалом выбранной платформы автоматизации в той достаточной мере, которая позволит сформулировать требования для разработчиков системы автоматизации и того, кто ее будет внедрять.
Поэтому готовность «профи» работать без ТЗ или позиция «нету ТЗ – давай до свиданья» – явные сигналы к тому, что с такими подрядчиками нужно прощаться как можно быстрее. Первые постараются «посадить вас на иглу» постоянных доработок с выставлением помесячных актов. Вторые умоют руки при появлении первых же проблем.
Вывод: формализованные, задокументированные требования, конечно, должны быть. Но в данном случае ответственность заказчика – создать бизнес-требования, на основании которых привлеченные для выполнения проекта специалисты предложат варианты – как эти требования можно реализовать в функционале внедряемой системы.
Затраты на фазу бизнес-анализа (оценка из практики) составляют относительно небольшую часть проекта – около 10% бюджета.
Возможные потери: +50…100%, по сравнению с бюджетом проекта с документированными требованиями.
Не усложняй простые вещи!
Эту фразу еще можно услышать от руководителей самого высокого уровня. «Не городите огород! Просто начните и сделайте это!» – говорит директор своему топ-менеджеру, предлагающему применять проектный подход. Надо ли говорить, что любой, даже самый простой проект, обречен на затяжной прыжок в пропасть с взаимными претензиями и поиском виновных, если он:
- Не узаконен в структуре ответственности компании (не определена ответственность владельца проекта и руководителя проекта)
- Не ограничен сроками
- Нет четкого бюджета и четких целей
По моему опыту и оценкам, формальные признаки проекта (приказ, устав, план, бюджет, финальный отчет) имеют не более четверти проектов автоматизации, которые длятся от полугода и стоят компании от $50K до $100K. В более крупных проектах ситуация получше.
Возможные потери: +100…200% лишнего времени, по сравнению со сроком реализации такого же проекта, но в котором применялся проектный подход.
Сначала внедрим, потом разберемся
Этому подходу «сто лет в обед». В некотором роде это сочетание первой и второй ошибок.
Подход часто встречается в небольших проектах. Берется «коробка» продукта или платформы, инсталлируется. В программу (у меня язык не поворачивается назвать это «системой») «загоняются» пользователи, которые должны начать там работать. Ожидается, что система начнет эффективно работать сама собой, естественным старением – по мере наполнения данными и выполнением отдельных настроек и доработок. Удачи!Управленческая система – это не только выбранная платформа. Это еще:
- Определение владельца системы и его обязанностей
- Цели и показатели успеха системы
- Методология
- Структура ответственности (проработка ролей всех участников системы)
- Модели процессов, выполняемых в системе
- Управленческие и процессные регламенты
- Шаблоны и формы первичных документов
Входная информация для создания требований к информационной системе должна быть разработана до начала автоматизации (и будет доработана в процессе проектирования информационной системы).
При комплексной постановке управленческой системы в этом случае превосходно работает связка автоматизаторов – со специалистами по управлению. Первые хорошо знают платформу автоматизации. Вторые выступают бизнес-архитекторами системы.
Возможные потери: до 100% затрат на систему (при необходимости постановки системы заново), дискредитация выбранной платформы, упущенное время на неудачную попытку.
Это же типовое решение!
Присматриваете для себя отраслевое решение (типовая для определенной сферы бизнеса система/платформа по автоматизации процессов, – прим. «Про бизнес.»). Решили примерить костюм, сшитый по чужой мерке?
Чем более специализированным является продукт («кредитный конвейер» для банка, CRM для автосервиса, документооборот для корпоративного центра), тем больше вероятность, что перед вами конфигурация, «заточенная» под специфику конкретной компании. Чем меньше в системе отраслевой специфики – тем дальше она от типовой.
Действительно хорошая типовая платформа представляет собой баланс между спецификой и универсальностью. Этот баланс найден разработчиками на основе опыта многочисленных внедрений.
В наши дни у вас больше шансов столкнуться с конфигурацией, которая уже была разработана для той или иной компании, и предлагается повторно. Проект «1+» (продажа продукта более одного раза) – мечта любого разработчика ИT-решения.Для ясности – я не выступаю против подхода «1+». Скажу даже больше: при высокой скорости инноваций вокруг, это едва ли не единственный способ развития продуктов. Просто не нужно недооценивать труд (и, как следствие, время и деньги!) на доработку системы под особенности вашего бизнеса.
Общий вывод: смотрите ли вы на проверенное типовое решение или на продукт «1+», – закладывайте серьезный бюджет на доработку системы для вашего бизнеса.
Возможные потери: некорректно считать потерями стоимость доработки «коробочной версии» (+50…200% к стоимости покупки готового ПО/лицензий). Но эти затраты станут большой неожиданностью!
Недооценка собственных трудозатрат на внедрение
Посмотрите на бюджет вашего проекта автоматизации. Надеюсь, вы уже оценили такие статьи, как:
- Стоимость ПО/лицензий
- Вложения в «железо» и инфраструктуру
- Услуги консультантов внедрения
- Обучение персонала
- ИТ-поддержка
Оцениваете ли вы время своих сотрудников, которое они должны отдать проекту? По опыту проектов разной сложности, уверенно могу сказать – бюджет времени (распределение затрат времени по видам его использования, – прим. «Про бизнес.») внутренней команды проекта, владельца проекта и руководителей, вовлеченных в проект подразделений, составляет 1-2 бюджета времени внешних внедренцев. Они-то свое время считают и выставляют вам свои счета. А вы считаете время своих людей?
Проблема даже не в себестоимости времени сотрудников, оцененной по их зарплатам с налогами и накладными расходами. Проблема в том, что на некоторое время проект затмит собой все другие начинания и проблемы, полностью завладев вниманием большого количества людей (а если не завладеет, то я опасаюсь за успех проекта).Отдаете ли вы себе в этом отчет? Не взялись ли вы одновременно за несколько таких важных проектов?
Пример. Украинская девелоперская компания выделила на проект внедрения проектного управления (на платформе Primavera) один день в неделю. Задумайтесь: один день в неделю компания выделила на внутренние совещания, встречи с разработчиками, опытную эксплуатацию и другие проектные задачи, отодвинув операционную деятельность на второй план. Мы говорим уже не о времени проектной команды (она работала на проекте full-time), а о времени всего «офиса». Проект успешный, к слову.
Возможные потери: возрастание проектных и операционных рисков бизнеса.
Еще одна обезьянка в ваш зоопарк
Любой специализированный софт, «узкозаточенный» под выполнение определенных задач, лучше универсальной платформы типа «все-в-одном». Специализированные системы CRM, PLM, MES, ECM лучше выполняют свои задачи, чем те же модули в составе 1С 8 или SAP.
Мачете лучше рубит лианы, чем швейцарский нож. Но если вы все время будете брать лучшие специализированные системы, через некоторое время вы обнаружите вокруг себя «зоопарк» систем.
Каждую систему нужно «кормить» и обслуживать (апгрейд, интеграция с другими системами, масштабирование). Каждая система порождает в компании уникальные компетенции. Вы уже догадались, что сотрудники, обладающие этими компетенциями, обеспечили себе пожизненный контракт независимо от своей производительности?Я не сторонник крайностей, и здесь тоже нужно найти баланс. Компания должна иметь универсальную платформу и ограниченное число (зависит от разнообразия деятельности, но не более 2-3 на бизнес-модель) специализированных систем для реализации основных бизнес-процессов.
Возможные потери: растущие в геометрической прогрессии затраты на интеграцию различных систем, зависимость от разработчиков систем и от сотрудников-носителей уникальных компетенций, длительная адаптация новичков.
Лучшее – враг хорошего
Затяжное согласование требований, бесконечные «хотелки», доработки доработок, технический долг… Знакомо? Или это ваш первый проект (и все еще впереди)?
С подвижностью требований в ИT-проектах борются гибкими (agile) методологиями. А вот бесконечные согласования – в ваших руках, как ни странно.
Чтобы избежать ненужных согласований, приведу пример метода компании Terrasoft. Она применяет в своих проектах «правило двух итераций». Это означает, что любые согласования (требований, прототипов, результатов) проходят в два движения (в обе стороны). Допустим:
1. Разработчики предлагают вам принять протестированный ими функциональный модуль.
2. Вы тестируете модуль, фиксируете замечания (в рамках несоответствия первичным требованиям для данной итерации) и отправляете их разработчикам (первая итерация приемки).
3. Разработчики устранили ваши замечания и снова предлагают попробовать продукт.
4. Вы пробуете, высказываете финальные замечания (все еще в рамках требований), разработчики их устраняют (вторая итерация, точка: с этим функциональным модулем закончили).
Когда обе стороны (и разработчики, и заказчик) заранее договорились и знают, что число «передач мяча» строго ограничено, обе стороны ведут себя ответственно. В особенности это дисциплинирует заказчика.
В конце концов, разве потери времени в проекте – это не ваши же деньги?
Возможные потери, если согласования затяжные: +30…100% к срокам проекта.
======================================================
Виктор Степанов
Партнер, консультант, руководитель ИT-практики компании «Ключевые решения». Опыт постановки проектного управления. Руководитель проектного офиса, проектов и стратегических программ. Автор и ведущий семинаров по управлению проектами. Разработчик решений по моделированию бизнеса.
Опыт реализации бизнес-проектов в различных областях: создание стеклозавода, создание производства аппаратуры передачи данных по проводам высоковольтных линий; создание управляющей компании фонда прямых инвестиций и пр.