sotrud.ru 1


РАССУЖДЕНИЯ О ЛОГИКЕ И ПРОСТОТЕ

Артем ЛЕДОВСКИЙ, заместитель директора по развитию

Muzz Buzz Franchising
Эта статья для руководителей производственных предприятий и их собственников. Людям, которые не участвуют в процессах производства товаров и услуг и не владеют бизнесами, написанное здесь не будет интересным.
К этому эссе меня подтолкнули три события:

1) я получил запросы от трех разных предприятий, с которыми я уже некоторое время выстраиваю отношения, рассказывая им, как создавать информационные системы управления; они спрашивают о методологии выбора платформы и интегратора для создания информационной автоматизированной системы управления (ИАС);

2) кондитерские компании «Спартак» (Гомель) и «Коммунарка» (Минск) сделали парадоксальный выбор программной платформы и интегратора для интеграции ИАС на своих производствах;

3) Министерство экономики направило мне запрос о том, какие у меня есть предложения по модернизации структуры национальной экономики.

Эти три события имеют общую природу.

Они – о простой человеческой логике.

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

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


1) методологию проектирования процессов для создания самой оптимальной системы их взаимосвязей;

2) процессную модель производства, которая позволяла управлять эффективностью и производить изделия в огромных количествах.

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

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

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

– управление отношениями с акционерами (собственниками);


– управление данными об изделии;

– управление маркетингом и продажами;

– управление снабжением;

– управление производством;

– управление финансами;

– управление активами (в том числе и производственными активами);

– управление персоналом.

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

Чувствую, что самое время, набрав полную грудь воздуха, пояснить основную мысль этого эссе:

1) все производства имеют одинаковую логическую структуру;

2) все производственные предприятия имеют одинаковую бизнес-модель;

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

Это очень просто и это очень логично. Любое обратное утверждение странно, так как оно противоречит логике и здравому рассудку.

В течение последних сорока лет люди создают информационные автоматизированные системы управления на производственных предприятиях. Делают это они потому, что автоматизация рутинных процессов уменьшает:

– стоимость процесса (не надо платить человеку за его выполнение – выполняет программа);

– время исполнения процесса (программа делает все быстрее);

– риск совершения человеком ошибки (программа не ошибается в логических задачах).

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


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

Для того чтобы правильно выбрать, необходимо знать простые и логичные вещи, такие же, какими руководствуются люди в процессе выбора, скажем, хлеба и пекаря. Хлеб должен быть вкусным, здоровым и питательным, а пекарь должен знать свое дело – рецепт и технологию. Что же должен знать тот, кто выбирает программную платформу и поставщика для интеграции ИАС? Ответ логичен и прост. Я уверен, что многие уже сами догадались. Тот, кто выбирает программную платформу, должен быть уверен в том, что:

1) программная платформа соответствует бизнес-модели предприятия;

2) поставщик знает бизнес-модель и технологию создания ИАС.

Видите, как все несложно?

Давайте разберемся, как создается ИАС. Ответим себе на вопросы: что должна из себя представлять платформа, что должен знать и уметь интегратор? Платформа – это взаимосвязанные программные обработки большей части процессов, поддерживаемых на предприятии. Представим, например, какое-нибудь предприятие, где работает, скажем, тысяча человек. Каждый из этой тысячи делает что-то на этом предприятии. Этих действий может быть 10-15 повторяющихся операций, как, к примеру, укладовщиков, а может быть и больше – несколько сотен, как, например, у администратора системы. Так вот, платформа должна содержать программные обработки, поддерживающие автоматизацию максимальной части этих процессов (идеально – всех, но такого не бывает).


Теперь давайте разберемся, как интегратор создает ИАС. При создании ИАС интегратор делает следующее:

1) создает бизнес-модель предприятия (мы с вами помним, что они все стандартные!);

2) определяет платформу, которая наиболее подходит предприятию (мы с вами помним, что платформа должна соответствовать бизнес-модели!);

3) определяет расхождение между функциональностью платформы и бизнес-моделью предприятия и формирует задание на доработку платформы в местах расхождения;

4) создает программные обработки в соответствии с заданием и тестирует платформу с доработками;

5) обучает пользователей, как работать с платформой, и, вообще, помогает пользователям эксплуатировать платформу, следуя бизнес-модели.

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

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

1) насколько программная платформа соответствует бизнес-модели;

2) насколько платформа технологична.

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


Поставщика необходимо оценивать только по его компетенции. Понять, компетентен ли интегратор, можно, задавая ему и самим себе следующие вопросы:

1) знает ли интегратор бизнес-модель производственного предприятия? Умеет ли интегратор создавать бизнес-модели предприятий (производственных предприятий)? Ну и пояснение. Модели создаются в прикладной программной среде специальными языками – нотациями. Соответственно, если интегратор имеет библиотеку моделей и умеет создавать новые при помощи нотаций, то бизнес-модель предприятия он, скорее всего, зарисует и потратит на это не так много времени. А если не умеет, то такого интегратора не нужно пускать на предприятие;

2) знает ли интегратор программные платформы? Как много платформ интегратор знает? Если интегратор не знает, какие платформы существуют в подлунном мире, то он, скорее всего, будет навязывать заказчику ту единственную платформу, с которой он, и интегратор, знаком. Если платформа заказчику не подходит, то: во-первых, у предприятия будут проблемы с «натягиванием» ее функциональности на свою бизнес-модель, а, во-вторых, интегратор вряд ли будет об этом знать, борясь с платформой, как Самсон со львом. Фактически интегратор, как популярная радио-передача, будет бесконечно создавать программные обработки по заявкам пользователей, а Франкенштейн, получающийся из такой работы, ни с ИАС, ни с бизнес-моделью нормального производственного предприятия не будет иметь ничего общего;

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


4) умеет ли интегратор составлять задание на доработку? Здесь все просто. Как правило, интеграторы умеют это делать. Это, наверное, первое и самое простое, чему учатся все интеграторы;

5) может ли интегратор программировать (писать программные обработки)? Есть ли у него программисты? Если нет своих, то есть ли договоры с теми организациями, где программисты есть? Если планируется большой объем доработки, например, если необъяснимо выбрана откровенно слабая платформа, то достаточно ли у интегратора программистов для выполнения такой задачи?;

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

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

В завершение мне хотелось бы снова вернуться к тем событиям, которые подтолкнули меня к этой небольшой работе. Министерство экономики просит меня сформулировать идеи по модернизации структуры национальной экономики, и, отвечая на эту просьбу, я хотел бы предложить следующее. Я предложил бы строить бизнес в нашей светлой и трудолюбивой стране, руководствуясь логикой и простотой. Я предложил бы перестать лить воду вверх, удивляясь, почему это мы не можем конкурировать на внешних рынках, да и свой-то защищаем от импорта лишь обильной очередью из пушек по воробьям – девальвируя многострадальный рубль.
№6 за 2011 г. журнала «ИТ-Бел»