Сложность ERP систем

Наверняка вы видели такую картинку.

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

Когда вы покупаете себе на домой, ну скажем, Windows 8 или Вашу Любимую Игру (хоть что-то вы покупаете, надеюсь?) вы ЛИЧНО принимаете решение о выборе этой системы, и лично будете ею пользоваться.

Так вот, в корпоративном секторе все не так. В процесс выбора, покупки и использования разделен между разными людьми. Есть:

• Тот, кто выбирает софт
• Тот, кто за него платит
• Несколько различных групп людей, кто им пользуется
• Тот, кто пишет разработчикам софта отчеты об ошибках и просьбы о доработках

И да, это все разные люди. В этом и есть корень проблемы, о чем сейчас я вам и расскажу.

Для более лучшего понимания проблемы можно ознакомиться с типовым процессом покупки информационных систем в крупных корпорациях.

Три ключевые проблемы, превращающие софт-конфетку в унылость:
1. В процессе покупки, ключевые решения принимают люди, которые не будут пользоваться софтом.
При покупке смотрят на стоимость и функциональность на уровне галки “может такое софт или или нет”. Вникать в то, КАК он это может и сравнить это с другими решениями слишком сложно для этих людей.
Более того, некоторого функционала нет, но продавец убеждает, что он появится ПОСЛЕ внедрения (см. п.6). В процессе покупки просто фиксируют, что такой то функционал нам пообещали.

Результат:
Ожидания заказчика совпадают с функциональностью продукта, ну, процентов на 50. Проблема в том, что корпоративный софт сложный и слишком универсальный. Покупатели не знают, как его правильно покупать, что можно настроить а что придется серьезно перерабатывать. Продавцы же, не вникая в тонкие потребности клиента, обещают больше, чем есть в продукте. Дьявол кроется в мелочах!

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

Результат:
Множество различных людей из различных отделов создают ПОТОК СОЗДАНИЯ, который выдается за перечень доработок, который будет ОПЛАЧЕН, если их разработать. И значит, он будет разработан!
Правда, когда сотрудник отдела Y просил сделать кнопку копирования, он не ожидал, что рядом появится еще кнопка клонирования из отдела Z, а также кнопка экспорта, перемещения, регистрации, и т.д. Но его-то кнопка разработана и претензии, вроде как, предъявить не к кому!

3. Информационные системы отражают бизнес-процесс компании, наложенный на универсальную болванку коробочной версии.
Они не просто ведут учет, они УПРАВЛЯЮТ деятельностью компании, и смена софта должна приводить к коррекции самих бизнес-процессов. Но в компании обычно нет тех людей, которые могли бы изменять процессы компании под софт.

Тот самый отдел развития в иерархии компании, который мог бы занять это место, стоит на корпоративной лестнице куда как ниже Производственного Департамента Х и не может указывать, как им работать. А установленная программа не ставила задачу придумать новый способ взаимодействия и лишь лоскутно объединила текущие процессы под одну крышу, немного подстроившись под сложившиеся отношения.

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

В общем, красивых корпоративных ERP систем в ближайшее время не ждите.

А теперь самое интересное! Кажется, в описанной схеме есть что-то не правильное. Вот ответы на часто задаваемые вопросы:

В: Почему бы заказчикам не покупать софт правильно, покупая 90% готового функционала?
О: Во-первых попробуйте, найдите такой софт, особенно если у вас в департаменте 200 человек. И кстати, если у вас нет департамента на 200 человек, то не уверен, что вы понимаете сложность проблемы.

Во-вторых, попробуйте сами выбрать софт из того что есть, например, для Депозитарного учета ^[3] (). Вы либо специалист по учету, либо ИТ специалист. И тем и другим вы станете ПОСЛЕ покупки и внедрения хотя бы ДВУХ систем. А это – 5-7 лет. Срок жизни софта — лет 5. А средний срок работы на одном месте в России – 3-4 года.

В: А почему бы не объединять и не согласовывать требования?
О: Во-первых, вы сможете это сделать сами через 5-7 лет (см. предыдущий пункт).
Во-вторых, написать требования на то, чтобы что-то добавить – легко. А вот на то, чтобы что-то изменить, объединить или удалить, для этого нужно взять на себя ответственность за то, что такое изменение ничего не испортит и устроит ВСЕХ. Никто из участвующих во внедрении обычно не может взять такую ответственность на себя.

В: У меня на работе такой софт. Я руководитель того самого департамента на 200 человек и я хочу попытаться что-то сделать. Что делать то?
О: Сложный вопрос. Как и с пробками в Москве, здесь нельзя придумать одну волшебную пилюлю. Дам один совет:
В процессе внедрения обычно есть хотя бы один человек, кто пытается уменьшать количество разнородности в системе. Бывает, это молодой сотрудник с “низким весом”. Бывает, что этот человек со стороны компании разработчика.
Так вот, сманите его себе на работу, дайте должность “аналитика информационной системы”, и дайте ему только одно задание — “уменьшать количество кнопок”.
Пусть он пишет документ, в котором попытается описать последствие уменьшения процессов в системе и последствие для всех пользователей. А потом ходит и согласовывает эти требования со всеми руководителями отделов.
Пусть это будет его единственной работой. И может быть у Вас будет лучшая в мире система.

Я постарался рассказать свое личное мнение о том, почему ERP системы выглядят вот так:

Может быть именно Вы будете тем самым человеком, кто сможет решить эту проблему.
Знаешь, как изменить этот мир? Добро пожаловать в комментарии!

Автор: Joshua

Источник ^[4]