Наверняка вы видели такую картинку.
Все, абсолютно все мои коллеги, друзья, знакомые, даже я сам смеюсь над этими горе-разработчиками, захламившими программу кнопками, ссылками и прочим шлаком.
Хотя мне то что смеяться. Я, как архитектор ERP систем, сам регулярно прикладываю к этому свои руки, и понимаю, откуда возникает такой хаос.
Когда вы покупаете себе на домой, ну скажем, Windows 8 или Вашу Любимую Игру (хоть что-то вы покупаете, надеюсь?) вы ЛИЧНО принимаете решение о выборе этой системы, и лично будете ею пользоваться.
Так вот, в корпоративном секторе все не так. В процесс выбора, покупки и использования разделен между разными людьми. Есть:
- Тот, кто выбирает софт
- Тот, кто за него платит
- Несколько различных групп людей, кто им пользуется
- Тот, кто пишет разработчикам софта отчеты об ошибках и просьбы о доработках
И да, это все разные люди. В этом и есть корень проблемы, о чем сейчас я вам и расскажу.
Для более лучшего понимания проблемы можно ознакомиться с типовым процессом покупки информационных систем в крупных корпорациях.
- На высоком уровне примется Стратегическое Решение О Развитии Информационной Среды Предприятия. В этом документе будет много таких слов как «интеграция бизнес-процессов», «повышение производительности труда» и «увеличение отдачи на капитал».
- Под это выделят бюджет и, например, создадут группу взаимодействия по информационному развитию. А может в компании уже есть такой человек возглавляющий Отдел Развития Информационных Систем.
- Отдел развития создан не просто так, он проводит тендеры, делает запросы, уведомление о намерениях, рамочный договор и другие интеграционные действия.
- Представитель компании «Лучший софт» решил поучаствовать в тендере. Он подготовил презентацию, выступил. И, допустим, по странной случайности, именно у этой компании в итоге начали приобретать программу. При этом программа стоит 100 рублей и еще в 200 рублей оценивают внедрение. Это важно! Чаще всего внедрение стоит дороже софта, потому что… см. п.п.6
- Начинается этап внедрения.
- Приезжают консультанты и «настраивают» (т.е. дописывают на 50%) софта.
Бинго! Это очень важный пункт! На 50% ERP система на конкретном предприятии не является коробочным продуктом а пишется в кратчайшие сроки под названием «настройка».
Неплохая статья на эту тему от А. Попова. - Проект запускается, пользователи департамента Х используют программу.
- Все ошибки и доработки централизованно собирает отдел ИТ поддержки и отсылает производителю.
- Раз в два-три месяца производитель обновляет программу.
Три ключевые проблемы, превращающие софт-конфетку в унылость:
1. В процессе покупки, ключевые решения принимают люди, которые не будут пользоваться софтом.
При покупке смотрят на стоимость и функциональность на уровне галки “может такое софт или или нет”. Вникать в то, КАК он это может и сравнить это с другими решениями слишком сложно для этих людей.
Более того, некоторого функционала нет, но продавец убеждает, что он появится ПОСЛЕ внедрения (см. п.6). В процессе покупки просто фиксируют, что такой то функционал нам пообещали.
Результат:
Ожидания заказчика совпадают с функциональностью продукта, ну, процентов на 50. Проблема в том, что корпоративный софт сложный и слишком универсальный. Покупатели не знают, как его правильно покупать, что можно настроить а что придется серьезно перерабатывать. Продавцы же, не вникая в тонкие потребности клиента, обещают больше, чем есть в продукте. Дьявол кроется в мелочах!
2. Во время внедрения ключевые решения принимают люди, которые не будут пользоваться софтом.
Внедрение обычно идет сумбурно. Как говорил, по факту 50% софта дописывается на месте.
Сбор требований идет примерно так: множество мелких руководителей отделов, чьи подписи будут стоять на акте внедрения, вначале проекта на этапе сбора требований, как раз тогда, когда понимают меньше всего, пишут разношерстные требования с очень простой структурой: «добавить кнопку, которая будет делать то-то».
Результат:
Множество различных людей из различных отделов создают ПОТОК СОЗДАНИЯ, который выдается за перечень доработок, который будет ОПЛАЧЕН, если их разработать. И значит, он будет разработан!
Правда, когда сотрудник отдела Y просил сделать кнопку копирования, он не ожидал, что рядом появится еще кнопка клонирования из отдела Z, а также кнопка экспорта, перемещения, регистрации, и т.д. Но его-то кнопка разработана и претензии, вроде как, предъявить не к кому!
3. Информационные системы отражают бизнес-процесс компании, наложенный на универсальную болванку коробочной версии.
Они не просто ведут учет, они УПРАВЛЯЮТ деятельностью компании, и смена софта должна приводить к коррекции самих бизнес-процессов. Но в компании обычно нет тех людей, которые могли бы изменять процессы компании под софт.
Тот самый отдел развития в иерархии компании, который мог бы занять это место, стоит на корпоративной лестнице куда как ниже Производственного Департамента Х и не может указывать, как им работать. А установленная программа не ставила задачу придумать новый способ взаимодействия и лишь лоскутно объединила текущие процессы под одну крышу, немного подстроившись под сложившиеся отношения.
Результат:
В компании нет человека, кто мог бы взглянуть на программу «в целом» и при этом обладал достаточным весом для осуществления изменений в деятельности компании. Поэтому софт уже глобально не изменится, и будет именно таким всю жизнь.
В общем, красивых корпоративных ERP систем в ближайшее время не ждите.
А теперь самое интересное! Кажется, в описанной схеме есть что-то не правильное. Вот ответы на часто задаваемые вопросы:
В: Почему бы заказчикам не покупать софт правильно, покупая 90% готового функционала?
О: Во-первых попробуйте, найдите такой софт, особенно если у вас в департаменте 200 человек. И кстати, если у вас нет департамента на 200 человек, то не уверен, что вы понимаете сложность проблемы.
Во-вторых, попробуйте сами выбрать софт из того что есть, например, для Депозитарного учета (). Вы либо специалист по учету, либо ИТ специалист. И тем и другим вы станете ПОСЛЕ покупки и внедрения хотя бы ДВУХ систем. А это – 5-7 лет. Срок жизни софта — лет 5. А средний срок работы на одном месте в России – 3-4 года.
В: А почему бы не объединять и не согласовывать требования?
О: Во-первых, вы сможете это сделать сами через 5-7 лет (см. предыдущий пункт).
Во-вторых, написать требования на то, чтобы что-то добавить – легко. А вот на то, чтобы что-то изменить, объединить или удалить, для этого нужно взять на себя ответственность за то, что такое изменение ничего не испортит и устроит ВСЕХ. Никто из участвующих во внедрении обычно не может взять такую ответственность на себя.
В: У меня на работе такой софт. Я руководитель того самого департамента на 200 человек и я хочу попытаться что-то сделать. Что делать то?
О: Сложный вопрос. Как и с пробками в Москве, здесь нельзя придумать одну волшебную пилюлю. Дам один совет:
В процессе внедрения обычно есть хотя бы один человек, кто пытается уменьшать количество разнородности в системе. Бывает, это молодой сотрудник с “низким весом”. Бывает, что этот человек со стороны компании разработчика.
Так вот, сманите его себе на работу, дайте должность “аналитика информационной системы”, и дайте ему только одно задание — “уменьшать количество кнопок”.
Пусть он пишет документ, в котором попытается описать последствие уменьшения процессов в системе и последствие для всех пользователей. А потом ходит и согласовывает эти требования со всеми руководителями отделов.
Пусть это будет его единственной работой. И может быть у Вас будет лучшая в мире система.
Я постарался рассказать свое личное мнение о том, почему ERP системы выглядят вот так:
Может быть именно Вы будете тем самым человеком, кто сможет решить эту проблему.
Знаешь, как изменить этот мир? Добро пожаловать в комментарии!
Автор: Joshua
