Исходите из реалий жизни

Начнем с такого нетривиального утверждения - проектный бизнес очень хорошо иллюстрирует диалектический принцип перехода количественных изменений в качественные. Количество нарастающих проблем порождает необходимость поиска совершенно нетривиальных решений. Мы напрягаемся, решаем проблему - и переходим в новое качество. Затем наступает период спокойного развития событий, некоторое время работа идет в регулярном режиме. Потом проблемы снова накапливаются, создавая очередную "революционную ситуацию", - и снова героический прорыв. Таким образом, развитие обычной организации, как правило, идет ступенчато.

Подход к внедрению наиболее мощных ERP-систем - таких, как SAP R/3, Oracle, Baan, таков, что ряд предприятий, на наш взгляд, к нему просто не готов. Фактически предлагается "прогнуть" структуру вашей организации под достаточно жесткую систему. А ведь ключевой вопрос автоматизации чего бы то ни было - это не вопрос выбора наилучшего программного обеспечения или наилучшей бизнес-модели. Это вопрос учета всего базиса понятий организации.

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

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

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

На данном этапе важно, какая именно происходит автоматизация - заказная или внутренняя. Если заказчик и подрядчик - одна организация, то формальное техническое задание может занять полторы страницы, а все детали могут согласовываться в рабочем порядке, в процессе отработки понятийной базы. Если вы заказываете автоматизацию внешнему партнеру, то придется написать ТЗ страниц на сорок и в этом ТЗ отразить всю свою понятийную базу. Даже если речь идет об элементарном тестовом примере, вам придется потратить часы только на написание письма, из которого стороннему исполнителю будет понятно, что именно вы имеете в виду. А у нас, например, очень сложный склад, и реализация нашей идеологии в заказной системе требует отдельных значительных усилий для реализации существующей идеологии. Мы разделяем функции, возложенные на складских работников, и функции менеджеров, которые ведут те или иные заказы, - чтобы менеджеры не мешали управлять размещением товара на складе, а кладовщики не дергали менеджеров всякий раз, когда им нужно переложить коробку с одного места на другое. За день на складе может совершаться масса внутренних операций, но это не должно касаться продавцов.

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

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

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

Автоматизация не просто дает нам возможность получать необходимые балансы так часто, как мы хотим, хоть раз в неделю. На любом серьезном предприятии есть в том или ином виде структура, выполняющая функции планирования, - так называемый планово-экономический отдел. Решения о закупках, маркетинговых мероприятиях, объемах рекламы, расширении или сужении тех или иных областей деятельности принимаются исходя из каких-то критериев, показателей. Но пока у вас нет доступа ко всему объему оперативных данных, вы принимаете эти решения по большей части "из головы". И совсем другое дело, когда эти оперативные данные у вас есть.

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

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

Одна из проблем полноценной поддержки своей собственной системы - ее документированность. Легко сказать: "Наймите технического писателя". Этот человек, для того чтобы писать документацию, должен быть максимально погружен в систему... Одним словом, стремление держаться собственной системы всегда будет упираться в какие-то человеческие проблемы. В случае покупной системы всегда можно обучить специалиста; а если ситуация у вас сложится так, что вы останетесь без людей, которые писали и знают эту систему, куда вы пошлете нового человека учиться?

Если вы покупаете систему, то начальные вложения сравнимы с полным циклом создания собственной системы, а вложения в поддержку системы, естественно, меньше. Правда, очень большая головная боль - сам выбор покупной системы. Сейчас мы изучаем рынок, все отечественные, все западные системы, представленные в России, - десятки систем. У нас есть четкое представление о том, чего мы хотим, какими свойствами должна обладать информационная система. И мы в любом случае уверены в том, что информационная система крупного предприятия должна позволять администратору системы настраивать логику жизни предприятия, исходя из бизнес-процессов. Иными словами, крупному предприятию нужна система, построенная "от бизнес-логики", а не "от бухгалтерии", как большинство отечественных и ряд западных систем. Ведь Главная книга - это лишь одна из проекций жизни предприятия. И таких проекций очень много.

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

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

Что касается модели внедрения - как вы уже, вероятно, поняли, наиболее перспективной для крупных внедрений мы считаем модель, по которой проект ведет собственный ИТ-отдел предприятия, получающий необходимый ему консалтинг. Хотя для средних и мелких предприятий, не обладающих собственными ИТ-отделами, всегда будут нужны "выездные бригады"... Но пресловутый подход, при котором вы просто платите деньги за внедрение, после чего надеетесь сразу начать получать баланс, нам кажется нереалистичным.

Вы всегда должны исходить из реалий жизни. Можем поделиться такой историей - один из авторов этой статьи как-то задал очень крупному западному специалисту следующий вопрос: "Мне нужно учесть в картине бизнес-процессов возможность отказа наемной бригады от выполнения оплачиваемой работы в неурочное время. Как лучше это сделать?". Тот так и не смог ничего ответить...