Выбор КИС – история проекта
Компьютеры и программы как-то незаметно вошли во все аспекты нашей жизни - от повседневного быта до проблем глобального бизнеса и экономики. Мы это знали, готовились к этому, и это случилось. Процесс этот необратим, на счетах и арифмометре больше никто работать не умеет. Мир изменился, и мы изменились вместе с ним.
Еще десять лет назад были популярны споры о том, какой же экономический эффект “наносит” программное обеспечение. Сейчас очевидно, что бизнес-приложения создают стратегические преимущества для ведения бизнеса. Кто владеет информацией, тот владеет миром. Вопрос заключается в том, как же получить преимущества от автоматизации бизнеса.
Логично было бы обратиться к чужому опыту внедрений. Однако полная информация редко находится в открытом доступе. И если истории успешных проектов по автоматизации широко освещаются, то неудачные проекты, как правило, замалчиваются. Выяснить причины неудач и последовательность правильных действий – вот что нам нужно для собственного успеха с автоматизацией.
Мы изучали вопрос, связанный со значением такого шага, как правильный выбор системы: почему все же была выбрана та или иная система автоматизации для поддержки бизнеса? Знакомясь со статьями на эту тему, я заметил, что основание для выбора почти всегда определяется самыми общими словами (современная, гибкая, ERP или CRM, реализующая стандарт MRP2 и т.п.). Но о том, как проводился сам анализ или тендер по выбору, практически никогда не пишут. А между тем очевидно, что на этапе выбора системы закладываются предпосылки успешного проведения автоматизации.
Мы постоянно что-нибудь выбираем: выпить чаю или кофе, пойти в театр или в ресторан. Мы привыкли решать, но иногда выбор действительно сложен.
Карьерный рост таких людей как Владимир Кива из «Т.Д.Перекресток», Михаил Лазарев и «ОАО Кнауф», Андрей Хоробрых из «Илим Палп» произошел на фоне успешных проектов автоматизации.
Современные корпоративные информационные системы включают в себя тысячи полей баз данных, сотни отчетов, могут обслуживать миллионы транзакций и хранить данные годами и даже десятилетиями. Крупные системы пишут десятки разработчиков; их функциональность настолько обширна, что нет специалиста, знающего даже 50% функций.
Как было бы хорошо, если бы рынок КИС был подобен супермаркету, где все разложено по полочкам и красиво упаковано, а доброжелательные продавцы расхваливают очередной товар, тут же, на месте, демонстрируя его в действии!
Но корпоративная информационная система – не коробочный продукт, требует длительной настройки под клиента. Недостатки такого сложного пакета не всегда очевидны, и даже достоинства могут обернуться недостатками.
От последствий неправильного выбора фирма нередко страдает в течение нескольких лет – не говоря уже о потраченных впустую сотнях тысяч долларов. А стороной компании с точки зрения будущего проекта являлись потом, восстановив ущерб, предприятию придется рано или поздно вернуться к вопросу выбора пакета и… пройти всю цепь страданий и ошибок снова. Но этим будут заниматься уже другие люди. По моим наблюдениям, неудачный выбор всегда стоит карьеры того, кто отвечал за проект – второго шанса на том же предприятии им уже не дают. И наоборот – успешный проект всегда приводит к «ракетному» взлету карьеры руководителя.
В этой статье мы расскажем о профессионально проведенном проекте выбора системы. Надеемся, что этот практический пример будет Вам полезен.
Проект проводился для компании, работающей в нефтяной отрасли. Компания имеет большой оборот. Сильной высокий уровень бухгалтерского и управленческого учета и высокая квалификация персонала.
Инициатором проекта был финансовый директор, который был неудовлетворен функциональностью используемой корпоративной системы среднего класса. Эта система, внедренная почти десять лет назад, была написана под DOS и долгое время обеспечивала приемлемый уровень автоматизации, но от современного уровня эта версия системы безнадежно отстала.
Целью проекта был выбор корпоративной информационной системы, которая позволяла бы обеспечивать руководство компании информацией для принятия решений, выполнять обязанности перед государством и учредителями по обеспечению прозрачного учета в соответствии с российским законодательством и требованиями западного управленческого учета, и эффективно поддерживать бизнес-процессы.
Координатором проекта со стороны заказчика стал внутренний аудитор, хорошо знавший большинство бизнес-процессов компании и обладавший достаточным уровнем полномочий для организационной поддержки проекта.
Проект начался с определения бизнес-областей будущего внедрения.
Несмотря на кажущуюся простоту, разделить проект на бизнес-области непросто. При первоначальной постановке задач на предприятии эти области не были определены. Правильное структурирование бизнес-областей позволяет не упустить важные группы требований, лучше соотносить потребности с функциональностью систем и приоритезировать требования на уровне областей.
Современные компьютерные системы строятся по модульному принципу. Например, есть модуль «Главная книга» - он обеспечивает функциональностью работу сводной бухгалтерии. Есть модуль Закупки, который обеспечивает функциональность для ведения расчетов с поставщиками. Функциональное наполнение модулей различно, но в них, тем не менее, можно выделить общие элементы. Консультанты, используя такие знания о структуре систем, спроецировали ее на функциональные задачи предприятия. В результате были получены 12 бизнес-областей: бухгалтерский учет, учет капитальных вложений, учет основных средств, расчет заработной платы и кадры, бюджетирование, материально-техническое снабжение, складской учет, касса и банк, учет договоров, расчеты с контрагентами, подготовка управленческих отчетов (стандартных и по запросу), управление наличностью. Определение бизнес-областей – это первый шаг выбора, позволяющий на самом первом этапе соотнести будущую программу с потребностями предприятия.
Интервьюирование – задача несложная, но консультантам проводить интервью гораздо проще, чем сотрудникам самого предприятия. Начальник отдела охотно выделит время для общения с внешним консультантом, но может быть недоступен для внутреннего сотрудника.
Затем была проведена серия интервью с сотрудниками предприятия, которые представляли интересы каждой области. При интервьюировании важно уметь слушать, но так же важно уметь задавать правильные вопросы, связанные с выбором системы и тем, какие требования к будущей системе предъявляются. Часто человек довольно легко говорит о недостатках старой системы и может сформулировать требования, которые позволят их устранить в новой системе; в то же время он может не знать всех аспектов своей работы, которые можно улучшить.
Для выбора системы критерии выбора должны характеризовать целевое состояние. В этом заключается парадокс – целевое состояние связано с возможностями системы, но выбор системы должен обеспечить реализацию целевого состояния. Этот парадокс итеративно разрешается за счет участия бизнес- и ИТ-экспертов в проекте одновременно.
Другая проблема в том, что у каждого отдела и сотрудника свои функции, свое понимание задач будущей системы. Требования могут быть взаимоисключающими. Общей картины на уровне специалистов-исполнителей, как правило, нет. Зачастую его нет ни на каком уровне. Поэтому после проведения интервью была проведена работа по анализу, сведению и уточнению требований. Для этой работы нужны люди соответствующей квалификации и уровня. Мы обнаружили, что иногда улучшение может состояться не на данном участке работы, а в рамках его взаимодействия с другими подразделениями. Такие требования могут не быть заявлены пользователями напрямую, однако имеют большой потенциал с точки зрения оптимизации деятельности компании. Поэтому при проведении проекта особое внимание уделялось созданию концепции целевого состояния.
Часто ИТ-сотрудники стремятся получить самую современную по техническим характеристикам систему, что реально может не соответствовать потребностям бизнеса и потребует неоправданных затрат на ее эксплуатацию.
ИТ-специалисты безусловно знают технические спецификации, но объяснить конкретный выбор на основе бизнеса им трудновато. Поэтому они не могут адекватно приоритезировать технические требования. Например, возможность увеличивать количество пользователей (масштабирование): для предприятия с 50 пользователями неважно, что система может поддерживать 1000 пользователей.
Помимо функциональных требований, которые формулируются в основном будущими пользователями, была проанализирована техническая архитектура (сетевое, компьютерное обеспечение и программное обеспечение). Была изучена стратегия предприятия в области ИТ, долгосрочные и краткосрочные планы, навыки и предпочтения ИТ-специалистов. Эта информация, а также такие особенности компании, как удаленные филиалы, состояние и возможности организации связи, отраслевая специфика, легли в основу формирования группы технических требований к системе.
Вопрос о том, использовать ли на предприятии одну интегрированную систему или несколько специализированных, неоднозначен. Даже на среднем предприятии одновременно можно использовать несколько систем: например, отдельные системы под бухгалтерский учет, бюджетирование, для кадровой работы. Специализированная система более функциональна, но затраты на поддержку всего решения возрастают. Также возникает проблема повторного ввода и необходимости синхронизации данных в разных системах, соответственно возрастает вероятность появления ошибок. Идеальный вариант – одна система для всего бизнеса - наталкивается на проблему внедрения: интегрированную систему трудно поделить, а внедрение «широким фронтом» может лишить бизнес точек опоры.
В проекте ищется компромисс, основанный на минимизации количества систем при оптимальной функциональности.
В целом критерии были сведены в 4 группы: функциональные, технические, требования к поставщику, стоимостные. На первой фазе проекта были разработаны критерии отсечения, т.е. вопросы, на которые можно давать ответы типа да/нет. Это абсолютно бесспорные требования к системе, невыполнение которых делает проект бессмысленным. Таких критериев не может быть много. Например, в технической области был только один отсекающий критерий – система управления базами данных Microsoft SQL. Клиент уже закупил это программное обеспечение и имел сертифицированных специалистов по Microsoft, способных организовать эффективную поддержку. Самым важным критерием являлась способность системы поддерживать все бизнес-области, выделенные в ходе проекта. Исключение делалась только для подсистемы «Расчет Заработной платы и кадры», так как эта область является в значительной мере обособленной. Кроме того, Клиент уже использовал программу 1С Зарплата и Кадры, и вопрос о ее дальнейшем использовании оставался на тот момент открытым.
На начальном этапе в отборе должно участвовать максимальное количество систем. Исключать систему из выбора можно, только основываясь на критериях данного этапа. Если остаются сомнения, лучше провести систему в следующий этап выбора.
Параллельно с подготовкой требований к системе мы готовили начальный список систем для отбора. В нашей базе данных на тот момент было более 50 корпоративных систем (количество систем непрерывно растет).
Часть систем были исключены из рассмотрения уже на этой стадии, например, системы, поставщики которых не поддерживают Интернет-сайт по системе, и те, цена владения которыми слишком высока для этого проекта. Таким образом, на начальной стадии количество пакетов значительно сократилось еще до контактов с поставщиками систем. И все равно список был очень велик.
Мы разослали поставщикам, оставшимся в списке, информационное письмо с приглашением участвовать в проекте.
Уже на этом этапе мы столкнулись с трудностью, которая очень мешает в проектах по выбору: хотя большинство поставщиков реагируют на наши запросы по проекту оперативно, есть поставщики, которые присылают ответы несвоевременно, что приводит к затягиванию проекта. Мы обычно стараемся посылать запросы с запасом времени в дополнительную неделю.
Небольшая часть поставщиков отказалась от участия в проекте по разным причинам. Один из поставщиков сообщил нам, что имеет достаточно проектов на сегодняшний день. Очень своеобразен был подход к участию в проекте специалистов компании “Интерфейс”, которая пользуется нашим уважением благодаря своему профессионализму, но у которой, по нашим неоднократным наблюдениям, есть явные проблемы с информационным взаимодействием внутри компании. Когда мы позвонили с напоминанием о нашем предложении и попросили уточнить, будут ли они участвовать в проекте, нам ответили, что, вероятно, будут и вышлют в скором времени письмо. Ответа не было. Мы послали два письма, ответа мы так и не получили, но зато теперь мы регулярно получаем информационную рассылку этой компании.
Согласившимся участвовать в проекте поставщикам был направлен запрос на получение рекламной информации, описания основных характеристик системы и, самое главное, информации по отсекающим критериям. В результате анализа было отобрано 10 пакетов. Пакеты исключались нами не менее чем по двум отсекающим критериям. Мы исходим из того, что пакет, не соответствующий одному отсекающему критерию, может за счет оптимального соответствия другим требованиям заказчика компенсировать этот недостаток.
На следующей стадии мы послали запрос на коммерческое предложение, которое должно было включать в себя не только собственно коммерческое предложение, включающие стоимость, но и дополнительно ответы на вопросы по критериям. На этот раз мы включили в запрос не только отсекающие критерии, но и все критерии, которые нам удалось разработать на основании требований заказчика. Таких критериев мы разработали всего 340. Конечно, не все критерии равны по значимости для клиента. Поэтому каждому критерию присваивается вес в соответствии с его значимостью для клиента. Как мы указывали выше, критерии мы делили на группы: функциональные, технические, требования к поставщику, стоимостные. Такое деление не является обязательным, например, стоимостные критерии были поделены дополнительно на стоимость внедрения системы и качественные критерии. Под качественными критериями понимаются вопросы типа: требует ли дополнительных затрат добавление учета второй компании в систему? Вес всех групп критериев составлял 100 процентов, наибольший вес был у группы функциональных критериев – 33%, наименьшей - у стоимостных – 17%. То есть на данном проекте стоимость не являлась решающим показателем. У других проектов очень часто есть бюджет с четкими ограничениями по стоимости. В этой ситуации стоимость была бы отсекающим критерием. Стоимостные критерии легче поддаются анализу, поскольку они приводятся к количественному выражению. Оценка функциональности наиболее трудна для анализа, так как очень трудно дать сложной функциональности однозначное толкование.
Другая проблема - получение достоверной информации о системах. Прямое искажение фактов допускается продавцами редко, все-таки продажа систем – это одна из самых цивилизованных частей рынка. Но поставщики часто сообщали о системах только положительные сведения, приукрашивали картину. Например, очень часто давался ответ - можно дописать путем программирования при внедрении, хотя в нашем запросе было указано, что такой ответ равносилен признанию отсутствия соответствующей функциональной части. Но встречались и парадоксальные ситуации, когда в ответе на запрос было указано, что какой-либо возможности нет, а на последующей демонстрации выяснялось, что она присутствует. И это оказались лидеры проекта.
При выборе пакета поставщики являются, как правило, инициативной, активной стороной. У них есть стратегия продвижения корпоративной системы и хорошо обученные профессионалы-продавцы, использующие все возможности материального и морального стимулирования. Поэтому зачастую заставить поставщика следовать правилам выбора почти невозможно. Поставщики стремятся не максимально подробно ответить на вопросы всех заинтересованных подразделений заказчика, а выйти на верхнее руководство потенциального покупателя системы и убедить в стратегических преимуществах предлагаемой системы.
В профессиональных проектах выбора поставщикам выгоднее сообщать объективную информацию, так как это учитывается. Дело в том, что часть ответов проверяется путем, например, телефонного интервью. Мы сделали несколько звонков контактным лицам продавцов и задали вопросы по отдельным критериям. Например, критерий: “ Ведение номенклатурного справочника одновременно на русском и английском языках”. Не у всех пакетов двуязычность поддерживалась в полном объеме. В дополнение к этому, на данном проекте мы пришли к выводу, что проведем уже на этом этапе просмотр демонстраций всех 10 систем. В план демонстраций входили все ключевые вопросы из запроса на коммерческое предложение. В демонстрациях вместе с нами участвовали представители заказчика – координатор проекта и заместитель главного бухгалтера.
Особенность таких демонстраций - жесткий лимит времени: за 3-4 часа надо просмотреть систему в целом. При этом поставщики настаивали на предварительном рассказе о своей компании, технологиях, людях. И так просили об этом, что отказать в такой малости мы им не могли. Но иногда это выливалось в полуторачасовую лекцию.
Во время демонстраций представители поставщиков нередко пытались убедить проектную команду в том, что демонстрируемый пакет обладает замечательными свойствами, которые просто по нелепому стечению обстоятельств нельзя продемонстрировать именно сейчас. Аргументы варьировались от чисто эмоциональных: ”Хотите, я Вам поклянусь?” до неприкрытой демагогии: “Наша система может все”.
К чести поставщиков, к критике конкурентов они прибегали не так уж и часто. Но некоторые рубили сплеча. Так, в рассказе о достоинствах предлагаемой системы у одного из представителей прозвучала фраза: “SAP рядом не валялся».
Некоторые аргументы заслуживали большего внимания. Во время показа одного из пакетов специалисту удавалось продемонстрировать только небольшую часть функциональности. При этом он все время ссылался на то, что компания-поставщик провела множество внедрений системы и имеет более 700 баз, из которых можно собрать любую функциональность во время проекта внедрения. В той или иной ситуации все поставщики настаивали на том, что пакеты можно адаптировать при внедрении. Правда ли это? Несомненно. Но, как это часто бывает, когда продавец говорит с покупателем, – не вся правда. Действительно, некоторые системы позволяют дописать практически любой модуль. Но это деньги, остановки, сделанные в ограниченное рамками проекта время, и ошибки в программах, от которых сотрудников заказчика постоянно лихорадит. Нет смысла брать корпоративную систему среднего класса и переписывать. Но какую-то часть функциональности надо дописывать, и очень важно выбрать систему так, чтобы эта часть была минимальной.
Другой ловушкой продавцов бывают заявления типа: “Наша система очень гибкая, мы внедрим ее за 2 месяца”. Как правило, проектная группа после стадии сбора требований может назвать приблизительные сроки проекта внедрения. В зависимости от квалификации проектной команды внедрения, а также функциональности и адаптивности выбранной системы, сроки внедрения в дальнейшем могут колебаться, но, увы и ах - чудес не бывает - обычно в сторону увеличения сроков.
После каждой демонстрации участники проектной группы заполняли анкету с экспертными оценками по системам. Оценки выставлялись по впечатлениям от поставщика и от системы. Например, по поставщику: Доверие – оценка объективности поставщика, непротиворечивости обещаний, отсутствия преувеличений в описании возможностей системы; Дружелюбие – нацеленность поставщика на установление рабочего контакта в ходе проекта, стремление к долговременным партнерским отношениям с клиентом, понимание специалистами поставщика бизнес-этики, конструктивный подход к отношениям. По системе: Интегрированность – способность всех элементов системы действовать согласованно, создавать единое информационное пространство. В интегрированной системе дублирование (повторный ввод) информации и обмен данными сведены к минимуму. Интересно, что оценки одной и той же системы сильно варьировались у разных участников. На данный момент каждый из участников определил свой пакет-лидер.
Специалисты заказчика часто верят на слово, особенно если их убеждают уверенно, с рассказами о новых возможностях новых версий, со ссылками на проекты. “Мы стали лучше, система может гораздо больше”, - говорят представители поставщика. Но у проекта должен быть срок окончания работ. Если не принять решения о выборе на этом этапе, поставщики будут продолжать попытки запрыгнуть в уходящий поезд бесконечно.
После проведения демонстраций мы рассчитали средние оценки по каждому пакету. Мы обнаружили, что выделилась группа лидеров из 6 пакетов и группа аутсайдеров из 4 пакетов. На основании демонстраций мы сократили количество пакетов, участвующих в выборе, с 10 до 6. Оправданным ли было это решение, почему не 7 пакетов осталось? Мы постоянно перепроверяли наши заключения, так сказать, испытывали их на прочность, поскольку жизнь всегда богаче любой методологии, и опытный консультант всегда опирается на здравый смысл. Например, на этом проекте мы получили интересное доказательство правильности решения следующим образом. В самом конце проекта седьмой участник организовал повторную демонстрацию у клиента, который согласился посмотреть их как бы вне конкурса. Забегая вперед, скажу, что это происходило в самый выгодный момент перед завершением проекта, когда фактически определилось окончательное распределение мест. Демонстрация оставила хорошее впечатление, но не более того. Лидеры, как и предполагалось, больше подходили заказчику.
По оставшимся 6 системам был проведен количественный анализ ответов по критериям. Сначала производился подсчет суммы баллов по каждой группе критериев, а затем подсчитывался сводный результат. Итоги оказались очень ровными. Отсеяна была система, которая имела лучшие ценовые показатели. Но, как мы уже указывали, на этом проекте стоимость не была строгим ограничением. После длительного обсуждения, посоветовавшись с координатором проекта от заказчика, мы провели в финал 5 систем. В идеале мы должны были провести в финал 2-3 системы, тогда можно было бы сократить сроки проекта. Но решение должно приниматься, исходя из конкретной ситуации на проекте. Поэтому без одобрения заказчика мы не стали бы проводить в финал 5 систем. Влияние заказчика на ход проекта не ограничивается формулированием требований к пакету. На консалтинговом проекте очень важно, чтобы выводы были доказательны для заказчика. Если мы полностью уверены в наших выводах, то мы говорим – это наше профессиональное мнение, таковы результаты. Но если у нас есть сомнения, то надо сказать об этом заказчику, предложить приемлемые варианты и продолжать проект.
Очень важно понимать, что целью анализа на стадии отбора финалистов является не выделение лидера, окончательный выбор – это задача финальной стадии проекта. Мы стремились просто сократить список пакетов. Тем не менее, поставщики проявляли большой интерес к тому, на каком они месте. Действительно - любая из систем, попавших в финал, могла быть успешно внедрена у заказчика. Но нам предстояло выбрать то, что наиболее удовлетворяло бы требованиям заказчика.
Ключевой частью финальной стадии является демонстрация по сценарию. Под демонстрацией по сценарию мы понимаем пошаговую демонстрацию ключевых бизнес-процессов заказчика. В данном проекте это был процесс закупки материалов, очень сложный, с расширенными требованиями к функциональности. Например, требовалось показать в системе возможность передвижения контейнера с разнотипными товарами со склада на склад. Или необходимость отслеживать не только наличие заказа на товар, но и местоположение груза. Иногда сценарий делается со сквозным контрольным примером. В данном случае мы решили, что контрольный пример в сценарии такого уровня сложности был бы лишним. Действительно, не все поставщики смогли даже показать некоторые документы, например, «Заказ поставщику».
Вторым сценарием была подготовка бюджета и сбор фактов. Подготовка и выполнение бюджета затрагивает практически все подразделения заказчика. Кроме того, в бюджетировании было много специфики. Впрочем, были и вопросы, касавшиеся интерфейса – возможность копирования бюджета предыдущего периода, увеличение группы статей бюджета на определенный процент. Демонстрация по сценарию должна быть последовательной: важно, чтобы вопросы максимально соответствовали реальному процессу, а не были максимально сложными.
Оценка демонстраций по сценарию производилась на основе отчетов, которые заполнялись во время каждой из демонстраций. Отчет был построен на основе сценария демонстрации; дополнительные вопросы, не вошедшие в сценарий, не оценивались. Демонстрация велась последовательно по сценарию; в такой же последовательности заполнялся отчет по демонстрации, включающий таблицу критериев по сценарию.
Полученные результаты, как показывает практика проектов, намного объективней, чем попытки отвлеченного анализа.
Вот примеры возможных оценок:
|
Вес |
Комментарий |
|
|
Адекватное решение продемонстрировано |
100% |
Функциональность может быть внедрена без изменений |
|
Решение третьего поставщика |
10% |
Функциональности нет, есть не интегрированные решения у третьих поставщиков или в других системах, оценка близка к нулю |
|
В следующей версии |
10% |
Равноценно устной ссылке на возможность, неизвестно, какой объем из продемонстрированной функциональности войдет в следующую версию |
|
Отсутствует консультант |
10% |
Это равноценно устной ссылке на возможность |
В конце дня на фасилитационной сессии обсуждались результаты демонстрации, заслушивалось мнение сотрудников отдела бюджетирования, МТС и бухгалтерии. Консолидированное мнение входило в отчет по каждой системе.
Демонстрации по сценарию очень трудны для поставщиков. Специалист по продажам пакета запрограммирован на тот сценарий, который он многократно показывал на различных демонстрациях. Но сценарий поставщика призван показать наиболее выгодные стороны функциональности системы. Проиллюстрируем это утверждение на реальном примере.
Во время демонстрации одной из КИС специалист, показывавший пакет, очень убедительно показал, как создать простой отчет в очень короткое время. Но на предложение таким же образом показать, каких товаров в этом месяце продано больше, чем в прошлом, был дан ответ: написание отчета может занять весь день. Очевидно, что редактор отчетов – очень важная составная часть любой КИС, так как на любом предприятии требуется множество кастомизированных отчетов, дополняющих стандартные, входящие в систему, отчеты. Поэтому почти все поставщики демонстрируют простоту и гибкость редактора отчетов. Во многие системы встроен один и тот же редактор отчетов - Crystal Reports, о чем клиент, если это не IT-специалист, может и не догадываться. Но главное в отчете не быстрое рисование, а запрос к базе данных. Если база данных плохо спроектирована и документирована, то некоторые отчеты своими силами клиент реализовать не сможет. Поэтому редактор отчетов, как и другую функциональность, надо проверять на примерах из сценария.
Наблюдение показывает, что лучшей стратегией взаимоотношений поставщика и покупателя системы является кооперативное отношение. В особенности это важно понимать покупателю. Человек, который отвечает за автоматизацию, решает бизнес-задачу своей компании. И наиболее эффективно она может быть решена, если реалии бизнеса принимаются во внимание. Станьте хорошим покупателем, и у вас будут хорошие продавцы. Не надо переигрывать или обманывать продавца. Не надо пытаться получить все бесплатно. Учитывайте интерес продающей стороны и не злоупотребляйте чужим интересом в продаже. Тогда у продавца просто не останется выбора, и он начнет сам решать вашу задачу.
Поставщик не может долго готовиться к демонстрации по сценарию – не хватает времени и ресурсов. Поставщик продает то, что есть.
Поставщик не всегда может адекватно раскрыть особенности системы, а возможности демонстрирующих консультантов ограничены. Но, как правило, систему демонстрируют лучшие специалисты поставщика. Таким образом, уровень специалистов, демонстрирующих пакет, находится в тесной корреляции с уровнем специалистов, которые в дальнейшем будут внедрять и поддерживать систему. По сути, это одни и те же люди.
Демонстрация по сценарию была нелегким испытанием для поставщиков. Нередко во время демонстрации бывали ситуации, когда система валилась, выскакивали сообщения об ошибках. Не стоит придавать этому большое значение, демонстрация длится много часов, и у демонстраторов теряется внимание, накапливается усталость. Но, если функциональность в конечном счете не удавалось продемонстрировать, это, конечно же, сказывалось на оценке программы.
Большинство пакетов демонстрировались на реальных базах данных, слегка измененных под сценарий. Так, одна из систем демонстрировалась с валютой учета тенге. К нашему огромному сожалению, после нескольких попыток продемонстрировать возможности программы вести учет по правилам российского законодательства, демонстратором был запущен вариант системы с уже российской базой данных.
Были и другие забавные случаи. Так, во время одной из демонстраций по сценарию поставщики начали демонстрировать процесс бюджетирования не на той программе, которую должны были продемонстрировать, а на специализированной, очень дорогой программе бюджетирования. Впрочем, по нашей просьбе они все-таки показали бюджетирование в той программе, которая была запланирована, и довольно успешно.
Особенно нам понравился один из демонстраторов, который, показывая очередной пункт сценария, неизменно говорил: “А теперь я расскажу, как это происходит на самом деле”. Затем, к некоторому нашему удивлению, нередко показывалось именно то, что требовалось по сценарию.
Выводы демонстрации по сценарию были решающими для определения победителя. Но анализ проводился и по другим аспектам. Одним из сложнейших участков предстоящего внедрения должна была быть организация работы с удаленным складом. Имеющийся спутниковый канал связи имел недостаточную пропускную способность для прямого обращения к центральной базе; предполагаемой задачей системы была организация обмена данными между центральным офисом и удаленным складом. Приведу отрывок из анализа по техническим возможностям одной из систем: “Работа системы с одним сервером по тонкому каналу возможна только с использованием Terminal Server. У компании есть опыт внедрения распределенной системы. Данное решение основано на стандартных средствах MS SQL Server. Синхронизируются только финансовые данные, причем в одну сторону – т.е. данные подчиненных офисов консолидируются с данными головного”.
Несмотря на декларации, организация удаленных рабочих мест – по-прежнему слабое место всех поставщиков систем.
Анализ показал, что все финалисты имеют опыт организации удаленных решений, но реализация решения будет трудной и потребует значительных усилий на внедрении. Явных предпочтений не оказалось, поэтому вывод был: “Таким образом, по данному техническому критерию мы не можем исключить какую-либо систему”. Что ж, отрицательный результат – тоже результат.
В завершении проекта, как это обычно бывает на консалтинговых проектах, мы распечатали и подшили документы в папку по финальной стадии (всего по проекту получились 4 папки материалов) и провели финальную презентацию, где рассказали историю проекта и наши рекомендации. К нашей гордости, после трехчасовой презентации сотрудники заказчика продолжали задавать вопросы, в основном касающиеся будущих шагов: как заключать контракт, проводить внедрение, сколько времени займет переход на новую систему.
Мы не называем победителей, потому что они – лучшие именно для этого проекта, для требований конкретного клиента, они лучшие среди равных по мощи конкурирующих пакетов. Нет универсального решения: на других проектах будут другие победители.
Окончательные итоги подводятся на этапе контрактования, который еще не проведен и который расставит последние точки в борьбе за поставку корпоративной информационной системы. Дело в том, что одну и ту же систему можно получить по-разному: по различной цене, с разными условиями поставки, послепродажной поддержки, гарантиями. Но в этой ситуации идет установление договорных отношений и выбор внедренческой команды, и это уже тема для отдельной статьи.