Расписание семинаров

Нет событий

Что нам стоит КИС построить... Или как не потерять денег при внедрении корпоративной информационной системы

внедрение корпоративной информационной системы

Чем больше мифов мы развеем – тем нам дешевле будет жить.

Внутренний диалог потенциального Заказчика информационной системы…:

У нас проблемы с отчетностью – не собирается, делается долго, цифры не бьются и т.д.

Значит, у нас плохая программа для формирования отчетов.

Следовательно, надо заменить программу и все проблемы будут решены.

Так, а где взять такую новую программу? ВО! Обратимся к мировому опыту и известным брендам.

Все верно – если сотни внедрений, стоит сотни тысяч (а то и миллионы) – ошибки быть не может. Программа X - точно решит наши проблемы. Осталось выбрать внедренца программы X, который нам ее внедрит.

Кому хоть раз приходилось заниматься внедрением серьезных решений во всей компании целиком– узнали ситуацию? Именно так думает подавляющее большинство людей, собирающихся внедрить [впервые] то или иное программное решение на уровне всей компании.

После полутора – двух лет внедрения и потраченных нескольких сот тысяч (мне известны случаи и миллионов долларов) приходит понимание, что «проект в тупике, отчетности как не было, так и нет».

Те, кто приобрели такой опыт, понимают, что ошибка была в самом начале.

И хорошо, если вы были в проектной команде – вы приобрели бесценный опыт за чужие деньги, а если вы непосредственный Заказчик?

Тот, кто платит? Так где ошибка? Ошибка в 1 пункте.

С самого начала рассуждений. С постановки цели. В приведенном выше случае не цель ставится (что должно быть), а описывается текущее состояние (как есть сейчас). Далее, поскольку цель не зафиксирована, в логике рассуждений, между п.1 и 2 (проблемы с отчетностью –> плохая программа) происходит подмена реальной проблемы на то, через что мы проблему наблюдаем. И решение получается соответственно не влияющим на причину.

Примерно как отрубить голову гонцу, принесшему плохую весть... Напоминает анекдот, когда ночью один человек ищет ключи под фонарем и его спрашивают:

- Ты ключи здесь потерял?
- Нет.
- Так почему здесь ищешь?
- А здесь светло.

А можно как-нибудь пройти этот путь, снизив риски возможных потерь? Можно! Для этого придется более четко и въедливо разобраться, какие же у нас все таки проблемы, и как их будем решать. Благо, времени на это нужно в десятки раз меньше (по сравнению с проектом внедрения) и денег не потеряем.

Собственно, проект внедрения информационной системы ничем не отличается от любого другого проекта по созданию чего-либо нового. Например, постройки дома. С таким проектом и будем сравнивать – для наглядности.

Но, только если дом - материальный объект и в таком проекте понятны начальная точка (участок под застройку) и более-менее конечная («нууу, скажем – как у соседа, тока побольше чуток»), то в случае с улучшением системы отчетности и управляемости, все не так очевидно на первый взгляд. Цель вроде бы непонятна - но это только на первый взгляд. Посмотрим чуть более внимательно?

Начальная точка – вроде что-то есть, как-то работает, но не так как хочется (а как хочется – не сформулировано). Конечная – корпоративная информационная система (КИС).

Если провести опрос среди тех, кому по зарез нужны управленческие отчеты, что такое КИС, то более 80% ответят: это программа (и назовут ту, что им ближе) – потому что через программу отчетность и наблюдается.

Именно это заблуждение может привести к тому, что проект по внедрению (созданию) КИС будет завален еще не начавшись.

Потому что КИС - это не программа. Это совокупность организационно-технических мероприятий и методологии для решения вполне определенных задач (например, формирования набора управленческой отчетности). А если по русски – то это совокупность ответов на вопросы «что» (какие цели достигаем), «как» (методология и регламенты), «кто» (будет делать и эксплуатировать) и «чем» (технические средства в помощь).

Компьютерная программа здесь лишь средство (и ничего более), инструмент, с помощью которого построена КИС. Вот, при постройке дома используются различные инструменты – от экскаватора до стамески. Никому же не приходит в голову называть закупку этих инструментов конечной целью постройки дома? И здравый смысл подсказывает, что, купив, самые лучшие инструменты, еще не значит, что дом будет построен такой, какой рисовался нам в мечтах…

Как с помощью одних и тех же инструментов можно построить и дачный сарайчик, и трехэтажный особняк, так и с помощью одних и тех же программ можно создать как «систему выписки накладных», так и «интегрированную систему информационной поддержки управленческих решений и технологий управления компанией с системами расширенной аналитики и прогнозирования». Важно не «чем», а «что» и «как».

Первое: Готового не бывает - все надо настраивать.

Собственно, ни одна программа, будучи вытащенной из коробки, не является работоспособной. Даже Windows нужно настраивать и обновлять, что же говорить о бизнес приложениях? А купив модный нынче инструмент (SAP, Oracle, MBS Navision/Axapta или др., чуть менее известный) – приобретается именно инструмент. Такая система, будучи вытащенной из коробки – представляет собой практически пустой экран с кучей менюшек. Ну может быть еще набор каких либо шаблонов, которые можно использовать в своей работе. Чтобы за примером далеко не ходить, запустите Excel – чистое поле. Ну шаблоны готовые есть – их можно пользовать. Кстати, в своей работе вы часто использовали шаблоны MS Office? Вот примерно так же вам подойдут и то что идет в комплекте с «тяжелым» софтом «класса ERP».

Второе. Настройщик способен сорвать концерт.

Если продолжать следовать логике из начала статьи, то следующий шаг - это выбор тех, кто будет внедрять выбранный инструмент. И начинается период тендеров: программу выбрали - теперь выбираем одного или нескольких, кто ее будет внедрять.

И, поскольку, конечная цель проекта до сих пор четко не сформулирована, а делать уже пора, то на этом этапе очень большая вероятность того, что окажется: «Купили не то или наняли не тех...» В итоге можно наблюдать как проектные команды с героическим упорством и фанатичным блеском в глазах годами киянками сваи забивают или экскаваторами грядки вскапывают... Что, впрочем, не мешает вкусно кушать - ведь работа оплачивается сполна...

Если резюмировать, то ошибка в том, что покупается модный инструмент и потом им пытаются решать все проблемы, вместо того что бы решать задачи, подбирая для решения наиболее подходящий инструмент.

А ведь в проектах по созданию КИС надо всего лишь, руководствоваться простым здравым смыслом. Тем же самым, что и при реализации любых других проектов…

Третье. Здравый смысл: как вы лодку назовете, так она и поплывет.

Прежде, чем подписывать первую платежку - ответить самому себе всего на 4 вопроса:

  1. ЧТО (Что хотим сделать. – то есть какие именно показатели хотим изменить в результате. Если ничего не изменится, кроме внешнего вида на мониторе – то тогда чего, спрашивается, ради?).

  2. КАК (архитектурное проектирование основных компонентов. План здания, перечень основных компонентов изделия и способ их монтажа, информационные системы, их функции и способ интеграции и т.д.) На этом этапе уже можно оценить ориентировочную стоимость решения.

  3. КТО (организационная поддержка проекта как на стадии реализации, так и на стадии эксплуатации).

  4. ЧЕМ (выбор инструментов и материалов).

Ответив на эти 4 вопроса именно в такой последовательности – и получается проектное решение. Осталось уточнить смету, нарисовать план график и принять решение – нужно нам такое счастье за эти деньги или нет?

Заметили разницу с логикой в начале статьи? Если говорить про программу, то в этом списке вопросов она на последнем, 4 месте. Обычно же, первые 2 вопроса (ЧТО и КАК) затрагиваются очень поверхностно, без формализации и фиксации (типа, потом разберемся), а сразу выбирается программа, потом внедренец.

Кстати, на практике КИС - это не одна программа. Это набор различных программ (возможно, разных поставщиков), каждая из которых решает (и хорошо решает) задачу, для которой она предназначена. Ничего страшного в «лоскутной» автоматизации нет, если «лоскуты» сшиты воедино в рамках общей архитектуры.

Четвертое. Четко знать, что будет в итоге «целью» - лишь половина успеха, вторая половина – знать «КАК» прийти к этой цели – архитектура решения.

Справедливости ради нужно отметить, что все 4 компоненты должны присутствовать обязательно. Выкинуть хоть один и деньги и время скорее всего, будут потрачены впустую.

 

Попробуем разобрать более подробно каждый из 4 вопросов.

ЧТО. Или «зачем». Самый главный вопрос, четкий ответ на который - почти половина успеха всего проекта. Бесполезно начинать проект с целью «улучшить качество отчетности». Ведь что такое «качество» и как его «улучшать» никто не знает (понимают, что это хорошо и полезно, но что это такое не знают). Проведите эксперимент – попросите несколько человек (на разных уровнях управления) написать независимо что такое «улучшить качество отчетности» и потом сравните результаты. Если, конечно, удастся сравнить несравнимое

Или еще хуже: цель "внедрить систему X".

Вспоминается история про девушку, которая поставила себе цель поработать на радио. Пришла, поработала и после испытательного срока была уволена. При этом цель достигнута. То же самое и здесь – система будет внедрена. И даже с ней будут работать люди. И новых нанять придется. И оборудования докупить. Но ситуация с отчетностью останется той же: как получались отчеты не пойми как, так же и получаются. Разве что экран программы стал другой.

Вполне работоспособными будут формулировки такого плана:

  • «Снизить величину складcкого запаса на 20%».

  • «Сократить время поставки до 5 дней».

  • «Повысить оборачиваемость дебиторской задолженности до 10 дней».

  • «Повысить оперативность формирования экономической отчетности (прибыли/убытки, баланс, распределение прибыли) до 3 дней после закрытия периода с допустимой погрешностью таких-то и таких-то показателей в 7%».

  • «Довести обеспечение доступности товарного ассортимента на складе до 90%».

  • «Сократить объем производственного брака до 3%».

Вот примеры формулировки целей. Обратите внимание: на этом этапе нет ни слова о той или иной программе. Здесь сформулированы реальные бизнес-задачи, имеющие действительную ценность для бизнеса. Выгоду от решения некоторых из них можно довольно точно посчитать в деньгах.

Причем ни одна из этих задач не решается только покупкой какого-либо программного обеспечения. Что не удивительно – инструмент эффективен только тогда, когда его правильно и по назначению используют.

Пятое. Цель проекта должна быть проверяема (количественный результат) и сформулирована

ДО проектирования и внедрения (снизить себестоимость на 5%), а не после (потратили $250 000 и жалеем).

КАК. После постановки цели нужно решить, как наиболее эффективно ее решить. Эффективность измеряем соотношением «сроки – деньги (и прочие ресурсы) – объем решения (функционал)».

Это второй по значимости этап. Как спроектируем, так и будет. На этом этапе выстраиваются основные компоненты будущего решения и их связь между собой. В каком месте должна быть система автоматизации? Какая роль людей? Где свои сотрудники, а где чужие? Кто какие данные получает, куда их вводит и что происходит дальше?

Например, если стоит цель повысить оборачиваемость дебиторской задолженности (ДЗ), то нужно решить, кто будет контролировать ДЗ: Бухгалтерия? Менеджеры по продажам? Выделенное подразделение?

Например, решили, что должны контролировать менеджеры по продажам (они могут не отгружать, если оплаты нет). ДЗ - это функция отгрузок и оплаты. Откуда брать эти данные? Допустим, отгрузки ведутся в самописной системе «Х» самими менеджерами, а оплаты вводит бухгалтерия в 1С.

Вот и прорисовывается та самая архитектура. Если упрощенно – взять отгрузки из системы Х, оплаты из 1С и вывести на рабочее место менеджерам. Заодно еще добавить лимит кредитования (который вводит кредитный контролер) и величину отсрочки платежа, которую можно взять из отдела договоров и которой сейчас нет в электронном виде.

Сведите эти 4 информационных потока вместе в одну точку и в одно время – и у менеджеров будет вся информация для контроля состояния ДЗ у клиентов. Понятно, что пример упрощен очень сильно, но даже при таком упрощении мы выделили основные блоки и зоны ответственности. Роли в будущей системе (не программе!) контроля ДЗ. На каждый блок уже сейчас можно расписать основной функционал, который должен быть в этом блоке.

А можно ли внедрить известную систему Y, в которой все это уже есть? Конечно, можно! Но только что «это все»? Функция контроля ДЗ? А заодно и склад, и логистика, и бухгалтерия? Если внедрить «все», то может быть и заработает. Но только:

  • В новой системе придется переписать реализацию всех 22 способов отгрузить товар, которыми вы пользуетесь, – потому что такие способы позволяют вам держать конкурентные цены. Нового ничего не получим – это у вас уже было реализовано.

  • В бухгалтерии заново настроить 18 финансовых схем проведения операций между вашими 12 юрлицами. А заодно заменить главбуха, потому что уважаемая женщина в свое время выучила 1С и ничего больше в глаза видеть не хочет и не может. В итоге получим нового бухгалтера, а недополучим чего?

  • Модуль склад заменить на «затычку», потому что известная система рассчитана на штрихкодирование, а мы не готовы на каждый из наших 10 маленьких складов ставить соответствующее оборудование. Результат – «затычка».

  • От логистического модуля отказаться вообще, потому что просто опасно объяснять пришедшим консультантам особенности документарного оформления пересечения товаром наших границ.

В итоге 90% проекта будет на переделывание того, что уже у вас сделано в имеющейся системе, и лишь 10% - на решение той задачи, которую поставили.

Конечно, если поставить цель «полная реорганизация циклов движения товаров и финансов», то интегрированная система будет более полезна. Но неужели действительно все так плохо везде? Не верю. Разве что вы создаете новый бизнес с нуля.

Проведя аналогию с домом, то если вы собрались пристроить гараж, нужно составить план участка, придумать с какой стороны будет гараж, провести необходимые замеры. Придумать, откуда взять и как провести электричество и воду. Решить, какие будут ворота и в каком месте стены прорезать дверь в сам дом. Имея на руках все эти чертежи, нанять людей, которые умеют их читать, - уже дело техники. Кстати, если четко знать чего хочешь – можно нанять и тех, кто умеет чертить...

А как вы поведете себя, если на задачу "пристроить гараж" вам будет предложено... снести дом и построить дом с гаражом? Звучит нелепо? А при внедрении «больших» ИТ решений такое случается сплошь и рядом...

Шестое. Архитектура – это письменно зафиксированные ответы «каким образом», «откуда», «кто делает», «как» по каждому функциональному блоку и движению информации. И тогда и только тогда – выбор программы (инструмента) будет обоснован.

КТО. На предыдущем этапе (архитектурное проектирование) мы определили основные компоненты будущей системы (функциональные блоки: в каком месте какие данные вводятся, как они собираются, обрабатываются и кому показывается результат) и функциональные роли сотрудников (кто из каких отделов работает с частями системы, какие данные вводят, какие смотрят и какие решения должны принять). На этом этапе нужно напротив ролей поставить фамилии. Кто конкретно и что будет делать. Причем, в 2 вариантах:

  1. Кто что делает на этапе создания системы;

  2. Кто что делает в процессе ее эксплуатации.

Поскольку эксплутационные расходы (явные и скрытые) зачастую превышают стоимость самого внедрения уже за первый год работы системы – о том, какими силами эксплуатировать созданное решение нужно думать уже сейчас.

Если в случае с внешними подрядчиками путь более менее понятен – объявляется тендер под четко сформулированные задачи (высокоуровневое ТЗ), то со своим персоналом не так просто. Сплошь и рядом встречаются ситуации, когда невозможно найти персонал достаточной квалификации в нужном количестве под внедренную модную систему.

Зачастую при принятии решения о внедрении системы класса ERP на заводе в регионах забывают (или из Москвы не считают важным), что средний возраст на оном заводе уже за 50 лет, что многие работяги в цехах (где по проекту должны быть рабочие места новой программы) не то что компьютером – калькулятором никогда не пользовались. Что размер пальца такого работяги – накрывает сразу 4 кнопки на клавиатуре...

Пример, конечно, утрирован, но проблема кадров стоит остро как никогда. Ради интереса посмотрите, сколько стоят сейчас специалисты по SAP, Oracle, Navision. Именно специалисты, а не те, кто прослушал курсы. Спросите у своего отдела кадров: сколько времени занимает поиск? Какая текучка в этой отрасли? Сколько вам нужно таких в штат, согласно проекту? Скольких надо обучить работать по новому? Все эти затраты и риски полностью лежат на вас – о них просто не вспоминают при составлении проекта, а зря.

Седьмое. Когда получены ответы на вопросы «что», «как» и «кто» – тогда и только тогда мы АВТОМАТИЧЕСКИ получаем техзадание.

ЧЕМ. Ну вот и добрались до выбора самой системы. Собственно, если мы честно дошли до этого пункта, то у нас уже практически готово тех задание. Функционал есть, роли есть. Осталось выбрать такой набор компонент, в котором все это можно реализовать дешево и в разумные сроки.

Если привлекаются внешние исполнители, то они, как правило, приходят и со своими технологиями. Если исполнитель подписывается под решение поставленной ему задачи, то так ли уж важно, как называется окошко программы, где этот результат будет решен? Ведь решение уникальное и под вас, и в какой оболочке сделано - уже не так важно (при условии работоспособности).

Здесь нужно выбирать, ориентируясь на критерии:

  1. Гибкость. Насколько легко переделать и доделать? Можно ли мелкие доработки делать самим?

  2. Открытость. Насколько легко и оперативно можно получать доступ к данным на чтение/запись выбранного приложения? Крайне важно для сопряжения с другими программами и решениями.

  3. Доступность специалистов по данному продукту. Сколько стоят, есть ли на рынке?

  4. Стоимость сопровождения. Что входит?

  5. Легкость обучения пользователей. Особенно актуально, если пользователей много, – их всех надо обучать работать в новой программе. Это обучение всегда оплачивается компанией в неявном виде.

Если будут делать свои специалисты, то выбор платформы для реализации примерно такой же. Есть, правда, маленькое отличие. Внешние подрядчики обычно работают под фиксированную сумму. И если сорваны сроки или не достигнут результат – есть все способы не дать раздуться бюджету проекта. А вот если делают свои – то зарплату платить надо и как страховаться от риска неудачи непонятно совсем. Но, справедливости ради, свои обычно стоят (за то же календарное время работы) раза в 2-3 меньше.

В настоящее время на рынке активно раздувается (есть версия, что сознательно) тезис о том, что чтобы решить проблемы с качеством и оперативностью отчетности, достаточно купить ту или иную модную (и недешевую) программу.

Однако это утверждение является широко распространенным мифом, приводящем к огромным рискам потратить деньги впустую.

Причем деньги - это еще полбеды: проваленные проекты приводят к подрыву доверия к ИТ-решениям вообще и, в итоге, к снижению конкурентоспособности, ведь информационная поддержка управления, будучи правильно отстроенной, действительно повышает скорость и качество принятия решений.

Программа является лишь инструментом, с помощью которого можно и дворец построить, и окончательно доломать имеющийся домик.

Для успеха проекта первостепенны четкость и конкретность постановки задачи, а также архитектура будущего решения и вторичен инструмент. Успешность решения выбранной задачи зависит в бОльшей степени от правильности архитектуры, нежели от используемых инструментов. Здесь основное правило – семь раз отмерь, один раз отрежь:

  • Готового не бывает - все надо настраивать. Не ищем готовых решений.

  • Настройщик способен сорвать концерт. Важно кто делает.

  • Здравый смысл: как вы лодку назовете, так она и поплывет. Если скажем «внедрить» - результат «внедрили». Если скажем «снизить себестоимость» - то и результат «снизили себестоимость».

  • Четко знать «ЧТО» будет в итоге (цель) - лишь половина успеха, вторая половина – знать «КАК» прийти к этой цели (архитектура решения).

  • Цель проекта должна быть проверяема (количественный результат) и сформулирована ДО проектирования и внедрения.

  • Архитектура – это письменно зафиксированные ответы «каким образом», «откуда», «кто делает», «как» по каждому функциональному блоку и движению информации. И тогда и только тогда – выбор программы-инструмента будет обоснован.

  • Когда получены ответы на вопросы «что», «как» и «кто» – тогда и только тогда мы АВТОМАТИЧЕСКИ получаем то самое, семь раз отмеренное техзадание.

Потому что многие могут позволить себе отрезать лишь один раз...

Успешных вам проектов!

Иван Варламов