Лента новостейИТ в бизнесеУправление
Анатолий Коробкин | 29.06.2017
В статье речь пойдет о некоторых предварительных этапах крупных проектов по автоматизации. Ведь нередко именно на этапе инициации проекта принимаются решения, в дальнейшем определяющие его успех или
провал. Причем успех понимается не с формальной точки зрения (сроки, объемы, бюджет), а с точки зрения заказчика (решение той проблемы, ради которой и выделялся бюджет).
А и Б сидели на трубе
Значительную часть времени ИТ-подразделение занято мелкими задачами. Но вдруг кому-то из высшего руководства приходит в голову мысль, что было бы хорошо вот это автоматизировать как-то иначе.
Руководство созрело для того, чтобы потратить существенную сумму на реорганизацию, и тем или иным образом доносит данную идею до сотрудника, ответственного за стратегию автоматизации. И вот вы
выходите от начальства окрыленный новыми перспективами или погруженный в тяжелые раздумья о том, почему именно на вас взвалили такой груз и за что вам все это.
Итак, ваша задача: выбрать платформу для автоматизации, разработать план, определиться с исполнителями, рассчитать бюджет, презентовать решение руководству и реализовать проект.
В самых легких случаях заранее понятны и платформа, и подрядчики. А если это вызывает серьезные вопросы? Если в силу каких-либо причин лежащие на поверхности и вдалбливаемые рекламой в мозги ответы
(например, Microsoft или «1C») вас не удовлетворяют?
Шаг 1. Рекогносцировка
Это очень важный шаг, который часто не принимают во внимание. Но пропуск подобного этапа зачастую приводит к тому, что в конце проекта руководство видит, что вы что-то автоматизировали, но не то и не
так. Задача, которая и заставила руководителя выделить вам бюджет, в итоге может оказаться не решенной.
Поэтому на данном шаге попытаемся ответить на следующие вопросы:
- Что именно не устраивает руководство в текущем положении дел?
- Какой результат руководство хочет получить на выходе?
- Как можно измерить требуемый результат?
- Какие подразделения будут задействованы в ходе выполнения проекта?
- Кто будет руководителем проекта?
- Кто будет куратором проекта?
Несмотря на кажущуюся простоту, ответы на первые три из этих вопросов могут быть неочевидны. Например, руководство может рассказывать вам про необходимость внедрить, наконец, CRM-систему, а на самом
деле ему нужна автоматизация работы колл-центра.
Или ставится задача навести порядок в учете входящих писем. Но при этом основная проблема заключается в том, что отдел продаж не успевает вовремя выставлять коммерческие предложения и готовить
документы для конкурсов. Но поскольку запросы и приглашения, как правило, приходят в письмах, которые теряются или откладываются на потом, проблема в голове руководства трансформируется в
необходимость контролировать отработку входящей корреспонденции.
После того как вы сформулировали ответы на первые три вопроса, их весьма желательно верифицировать. Организуйте еще одну встречу с руководством и проговорите постановку задачи, а главное, ожидаемый
измеряемый результат.
Перечень задействованных подразделений, оценка уровня их участия в проекте и влияния на общий результат также очень важны. Во-первых, чтобы определиться с куратором. Во-вторых, чтобы вовлечь
руководителей этих подразделений в работу на предварительных этапах проекта, учесть их интересы и требования, нейтрализовать возможные возражения.
Куратором (спонсором) не всегда должен быть инициатор проекта. Это должен быть представитель высшего руководства, заинтересованный в достижении сформулированного результата, имеющий достаточные
полномочия, чтобы контролировать ход выполнения работ всеми задействованными подразделениями, способный обеспечить выделение необходимого бюджета.
Очень желательно привлекать будущего куратора к обсуждению на самых ранних стадиях, даже до его официального назначения.
Бывает целесообразно отдать руководство проектом, который существенным образом меняет методы работы большого количества подразделений, в проектный офис, оставив за ИТ только технические аспекты.
Стремление примерить на себя лавровый венок победителя способно привести к необходимости надеть терновый венец ответственного за провал. Лучше взять на себя функции архитектора и с блеском их
выполнить.
Пример
Рассмотрим предыдущий пример с выставлением коммерческих предложений. Необходимо специфицировать каналы, через которые поступают запросы. Ввести их классификацию по категориям. Задать правила
отработки запроса по каждой категории. Отделить фиксирующих и контролирующих от исполняющих.
После того как процесс в самых общих чертах описан (обратите внимание, что речи о платформе для автоматизации еще не идет), нужно продумать механизм контроля над ним. Это может быть, скажем, набор
отчетов о ходе исполнения задач, о достижении промежуточных вех, о просрочках.
И лишь затем надо определить способы измерения процесса. На первый взгляд, очевидный критерий контроля — количество просрочек при выставлении коммерческих предложений. Следующее приближение к
правильному ответу — контроль среднего времени просрочки по всем проектам. И руководство может даже согласиться на подобные измерения, однако на самом деле его интересует повышение прибыли от
выигранных конкурсов. То есть абсолютно правильным ответом будет кривая роста прибыли компании, связанная с автоматизацией процесса.
Для построения кривой роста прибыли следует набрать статистику, построить воронку продаж за предыдущие два-три года. Если вы предложите руководству именно данный критерий, то станете с ним
разговаривать на одном языке. А такое взаимопонимание — залог роста и ваших доходов тоже. В результате обсуждений с руководством вы должны прийти к единой согласованной позиции по предмету
автоматизации и ожидаемым результатам.
Затем вы определяете задействованные подразделения (маркетинг, продажи, кол-центр, делопроизводители) и понимаете, что с точки зрения успеха проекта критичными являются первые два. Это может
привести вас к выводу, что куратором проекта предпочтительно назначить, например, коммерческого директора. Осталась самая малость — убедить в этом его и генерального.
Шаг 2. Ориентирование на местности
Второй важный шаг, который часто тоже упускают, — выбор платформы для автоматизации. Основная задача рекламщиков крупных фирм — тесно увязать те или иные типовые вопросы с продуктами именно этих
фирм. Люди ленивы и с готовностью идут туда, куда их ведут.
К примеру, когда-то рекламщики Microsoft пытались позиционировать MS Exchange как альтернативу Lotus Notes. Хотя любая попытка решить в рамках этого довольно простого почтовика хоть сколь-нибудь
нетривиальную проблему приводила к таким трудностям, что она становилась неподъемной. Дальнейшее развитие рынка устранило подобное противоречие, и теперь MS Exchange опять превратился просто в
почтовую систему. Но в результате данного противостояния появилась (очень сложно реализованная) возможность в MS Outlook разослать не просто письмо, а форму для заполнения. На тот момент выбор в
качестве платформы для автоматизации совместной работы пользователей продукта MS Exchange приводил с высокой долей вероятности к провалу проекта.
В итоге, если исходная задача решена криво, выбор известного продукта большой фирмы может оказаться одной из «отмазок». Ведь даже если в известном продукте (и руководство слышало название) столь
знаменитой компании (реклама на каждом столбе) задача реализована так плохо, то какие претензии к руководителю проекта? Он героически подставлял костыли под то, что натворили мировые лидеры! Аргумент
достаточно слабый, но в некоторых случаях помогает.
Отличительной чертой многих ИТ-специалистов является повышенная уверенность в истинности собственных представлений о реальности. Где-то случайно услышанная фраза, рекламный буклет или прочитанная
статья становятся фундаментом для безапелляционно высказываемого суждения. Так усилия рекламистов умножаются на некомпетентность исполнителей, выдавая в конце проекта освоение бюджета с сомнительным
результатом.
Поэтому не только слушаем инженеров, но и проводим широкий поиск всех возможных вариантов. Потом, если вариантов слишком много, вводим дополнительные критерии отсева.
В результате вы должны получить шорт-лист вариантов решения, состоящий не более чем из пяти пунктов. Для каждого пункта надо зафиксировать платформу для автоматизации, конкретную разработку на этой
платформе (если есть), оценку объема доработок, необходимость привлечения подрядчика и требования к нему.
Возвращаясь к примеру
Для нашего примера с коммерческими предложениями возможны два принципиально разных с технической точки зрения подхода.
В первом варианте мы используем платформу CRM для фиксации запроса пользователя и применяем встроенные механизмы отработки имеющихся запросов. Во втором — используем систему электронного
документооборота с настроенными маршрутами и фиксируем запрос в качестве поручения исполнителям. В обоих случаях должны быть предусмотрены возможности задать различные маршруты, сформировать
пользовательские отчеты, настроить нужные права доступа.
Детальный анализ этого конкретного примера может далеко увести от обсуждаемой темы, но я хотел показать, что даже для достаточно типовой ситуации подход к выбору платформы не предопределен. Выбор
может существенным образом зависеть от рынков, на которых компания работает, от уровня автоматизации, от уже развернутых платформ и существующей в компании оргструктуры.
Шаг 3. Требования
На этом шаге надо собрать все требования. Здесь важно не пропустить ни одной из заинтересованных сторон, которые потом смогут повлиять на успех проекта. К ним относятся:
- высшее руководство;
- руководители и ключевые сотрудники подразделений, напрямую участвующих в автоматизируемых процессах;
- руководители и ключевые сотрудники подразделений, которые будут являться потребителями того, что будет создаваться с помощью внедряемых вами решений. Помимо очевидных подразделений, являющихся
получателями результатов напрямую, не надо забывать про финансовые и другие службы, обеспечивающие контроль результативности автоматизируемых процессов; - сотрудники ИТ-подразделения, которым будут сопровождать внедренное ПО.
Требования высшего руководства выявляются и фиксируются на шаге 1. С остальными также надо работать на данном шаге. Для каждого требования мы должны фиксировать название требования, подробное
описание, обязательность, зависимость от других, кто и когда его сформулировал. Детально уточняйте уровень обязательности требования, поскольку в процессе выяснения оказывается, что оно, конечно же,
важное, но если будет реализовано другое условие, то необязательное. Источник важен, когда в процессе обсуждения возникает конфликт требований и надо выбрать одно из нескольких, взаимоисключающих.
Все требования надо верифицировать в других подразделениях или у других сотрудников. Источник и результат верификации также должны быть зафиксированы.
При этом следует достаточно осторожно относиться к требованиям от ИТ-подразделения. Ведь, скажем использование промышленных СУБД, открытость, интегрируемость, расширяемость, документированность —
очень важные аспекты с точки зрения жизненного цикла системы. Но тем или иным способом их можно обойти за счет увеличения стоимости сопровождения и снижения требований к уровню доступности.
Результатом данного шага должен стать сформированный и верифицированный список требований, ранжированный по степени важности. На его основе составляется перечень критериев для выбора решения и
подрядчика.
Шаг 4. Смотрины
Если решение возможно на нескольких разных платформах, причем внедрение будет проводиться силами сторонней организации, то выбор (как системы, так и подрядчика) целесообразно делать по результатам
презентаций. Каждый из претендентов должен рассказать о своей компании, о платформе, которую он предлагает, о путях решения вашей задачи с ее использованием и назвать примерную стоимость
решения.
Здесь очень важно довести до каждого участника вашу постановку задачи, собранные требования, возможные ограничения, в том числе по деньгам и срокам.
Надо помнить, что если вы работаете только с дилерами одного производителя, то можете нарваться на «договорняк». То есть решение о победителе конкурса будет принимать менеджер производителя, а не вы.
Остальные дилеры будут не биться за заказ, а «отбывать номер» в расчете, что потом их назначат победителями в другом тендере.
Важно обеспечить участие в смотринах экспертов от подразделений, вовлеченных в проект. Каждый эксперт должен для каждого варианта заполнить именной бланк по всем критериям отбора, проставив оценки по
предложенной вами шкале. Необходимо включить в бланк не только бизнес-критерии и технические вопросы, но и вопросы стоимости, а также пункты, связанные с оценкой возможности исполнителя (консорциума
исполнителей) выполнить свою часть в проекте.
Шаг 5. Подведение итогов
Формально подвести итоги презентаций очень просто:
- Назначьте каждому эксперту вес для каждого оцененного им критерия. Этот вес должен отражать компетенцию эксперта применительно к данному критерию.
- Назначьте каждому критерию вес, с которым он будет учитываться.
После этого рассчитайте результат по каждому критерию. Для этого перемножаем оценку на вес поставившего ее эксперта, все суммируем и делим на сумму весов экспертов. Получаем усредненную оценку по
определенному критерию.
Затем умножаем эту усредненную оценку на вес данного критерия и все эти значения суммируем. Получаем итоговый балл данного решения. Сравнивая итоговые баллы между собой, можно выбрать лучший
вариант.
А теперь про жизнь
В процессе отбора некоторые руководители могут вступить в неформальные отношения с участниками и что-то им пообещать. Особенно если бюджет большой. Поэтому, если ваша оценка пойдет вразрез с их
обещаниями, у вас могут быть серьезные неприятности. Вот почему необходимо заранее, еще до презентаций, огласить методику подсчета, согласовать веса критериев и веса экспертов и опубликовать их.
Создать тендерный комитет, во главе которого должен стоять куратор проекта. Публикация результатов должна осуществляться от имени тендерного комитета и подписываться его председателем.
А что делать, если выяснилось, что веса, присвоенные критериям заранее, до презентаций, не точно отражают требуемый вклад этих критериев в конечную оценку? Аргументировать это тендерному комитету и
изменять их с общего согласия, путем открытого голосования.
Пренебрежение открытостью как на этапе согласования критериев и весов, так и на этапе подсчета результатов, может поставить вас под удар, причем с совершенно неожиданной стороны. Поскольку вас
назначат «виновным» в том, что будут сорваны предварительные закулисные договоренности. В этом случае удар могут нанести по любой известной слабой точке, даже не относящейся к проводимому
тендеру.
Будьте бдительны, старайтесь заранее выводить себя из-под удара, не подставляйтесь! Хотя если вы являетесь любимым племянником контролирующего собственника, то все эти осторожности вам, наверное,
могут не понадобиться… Но это будет уже совсем другая история.
Теги: ИТ-директор, ИТ менеджер, руководитель, CIO, CRM
Горячие темы: Дерево решений
