Популярный анекдот в конце прошлого века.
Встречаются два предпринимателя.
Один другого спрашивает:
- Тебе нужен вагон сахара за миллион рублей?
Второй отвечает:
- Да, нужен.
- По рукам?
- По рукам.
И они расходятся в разные стороны . Один идёт искать вагон сахара, а второй миллион рублей.
А какие бывают встречи в наши дни, и чем они заканчиваются?
Встречаются Заказчик и Исполнитель.
Заказчик спрашивает Исполнителя:
- Сможешь создать на моём предприятии учётную систему за 30 миллионов рублей?
Исполнитель отвечает:
- Да, могу.
- По рукам?
- По рукам.
И они НЕ расходятся. У Заказчика есть 30 миллионов рублей и он готов
платить. И Исполнитель начинает работу. Они вместе действуют и двигаются навстречу друг другу, НО в одном направлении. Как в геометрии Лобачевского, по двум параллельным линиям, которые где то там далеко должны встретиться.
К сожалению, не редко бывает такое, когда при их встрече условия договора между Исполнителем и Заказчиком выполнены, но Заказчик остаётся «у разбитого корыта».
- В чём причина таких неудач? Рассмотрим Три примера:
Пример №1. Бизнес процессы в компании отлажены и автоматизированы. Программы хоть и с замечаниями, но работают и обновляются. И сотрудники уже привыкли к интерфейсам программ. Но, по закону возрастания энтропии (а этот закон действует не только в термодинамике), в базах накапливается мусор (в справочниках дубли, битые ссылки, элементы помеченные на удаление, которые почему то вылезают при заполнении форм и в отчётах). И в один прекрасный момент работа в такой базе перестаёт быть комфортной. А тут, как на зло, Исполнитель предлагает перейти в новую программу, где «всё летает и сверкает». И Заказчик соглашается. Исполнителя он знает не первый год, и пусть с замечаниями, но работали же с ним.
А вот здесь ВНИМАНИЕ, Заказчик!!! Не спеши устраивать революции, тем более в своей компании. Попробуй новую программу, но не на рабочем контуре. Создай новое Юр. лицо и пусть Исполнитель внедрит там новую программу без изменения типового функционала. Не надо на этом этапе тащить сюда тот опыт, который нарабатывали десятилетиями в прежней базе. Во первых этот опыт может оказаться не подъёмным для Исполнителя на данный момент, а во вторых может оказаться и устаревшим.
А после этого этапа внедрения посмотрите вместе с Исполнителем на текущие проблемы. И вместе решите, что, чем и как надо дополнить в этой новой базе. Потерь при этом точно не будет.
Пример № 2. Компания более Десяти лет самостоятельно внедряла программу. Вложила в неё опыт и знания лучших специалистов. И программа работает. Бывают моменты, когда пользователи обнаруживают ошибки. Но эти ошибки исправляются. Правда лучшие специалисты уволились. Уволились и некоторые топ-менеджеры. Но им на смену пришли другие. И всё бы хорошо, да только новые топ-менеджеры на прежнем месте работали с другой программой, там интерфейс был более красивый. И на совещаниях новые топ-менеджеры начинают убеждать Заказчика, что программу надо менять.
А вот здесь ВНИМАНИЕ, Заказчик!!! Как проверить, что новый топ-менеджер, желающий перейти на новую программу, действует в интересах компании? И не стремится создать себе комфортную среду для работы, игнорируя десятилетний опыт, который достался тебе потом и кровью? Пригласи на одно из таких совещаний прежних лучших специалистов. И пусть они посмотрят в глаза новым топ-менеджерам и новым Исполнителям. И пусть зададут вопросы о том, как в новой программе будет реализован требуемый функционал, и сколько будет стоить его разработка и сопровождение?
Пример № 3 возьмём из книги о работе на фондовом рынке. У Владельца крупного пакета акций появился новый Агент. Агент начинает искать информацию, которая может заинтересовать Владельца. И в один прекрасный момент сообщает ему, что на рынке идёт тихая скупка акций крупной компании состояние которой движется к банкротству.
Что делает Владелец в ответ на это сообщение? Он на глазах у Агента звонит своему Брокеру и выставляет несколько лотов на ПРОДАЖУ акций этой компании. Агент удивляется таким действиям Владельца и разочарованный уходит.
Через день Владелец сообщает Агенту о готовности оплатить информацию о скупке акций. И вновь Агент удивлён:
- Вы же не стали покупать, а наоборот продали акции этой компании. Почему Вы хотите мне заплатить? Вы же ничего не заработали на моём сообщении.
На что Владелец отвечает:
- Я проверил информацию которая мне интересна. Она подтвердилась. И я хочу её оплатить вне зависимости от того, как она будет мной использована.
А вот здесь ВНИМАНИЕ, Заказчик!!! Не бойся расстаться с сотней тысяч рублей, уходящей на проверку информации по проекту, в который ты планируешь вложить миллионы.
Вопросы по этим примерам:
Кто должен определять конкретные цели автоматизации в компании? Заказчик? Исполнитель? Сторонний Эксперт?
Наши проблемы начинаются там, где мы хотим получить ВСЁ и СРАЗУ. Чудес не бывает.
Двадцать лет назад при реализации проектов автоматизации управления действовал принцип — Не важно ЧТО автоматизируем, важно КТО автоматизирует.
Что изменилось за это время? Очень сильно возросли требования к функционалу и интерфейсам программ. Появилось ещё одно основное требование к программам. Какую бы специфику компании они не отражали — они должны обновляться. И их обновление не должно быть трудоёмким. Поэтому спрос на квалифицированных специалистов будет только расти. И на смену принципу - Не важно ЧТО автоматизируем, важно КТО автоматизирует, на передний план вернётся старый классический — Прежде всего ограничим список решаемых задач.