Главная / Статьи / Системы качества / Кому нужны заказные программы?

Кому нужны заказные программы?


Инженер Мареев

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

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

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

"СИСТЕМА НЕ МОЖЕТ ПОЗНАТЬ САМОЕ СЕБЯ"

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

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

Другое доказательство. Поставив себе задачей исследовать равномерность следования тактовых импульсов, система должна будет научиться измерять время, проходящее между тактами. Это невозможно, так как существование синхронной системы определяется изменениями ее состояния от такта к такту, и для нее не имеет смысла понятие промежуток времени между тактами.

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

Читатель может возразить, что не всякая фирма "существует только в головах и руках персонала", что лучшие образцы умеют "овеществлять" корпоративное знание и даже тиражировать его в своих филиалах. Для таких фирм замена персонала или начало работы на новом месте "с одного директора" – не проблема. Это абсолютно справедливое замечание, и мы еще вернемся к таким фирмам. Фирмы же "без царя в голове" будем для краткости пока называть "обычные" фирмы.

СПИРАЛЬ ПОЗНАНИЯ И СИСТЕМА КАЧЕСТВА

Японские, а вслед за ними и западные, теоретики качества, строят аналогию между разворачиванием спирали индивидуального познания и развитием системы качества корпорации как методом накопления коллективного знания.

Напомним, что "спираль индивидуального знания" формулируется следующим образом:

По отношению к фирме та же спираль познания показывает, как накапливаются коллективные знания по системе качества. При этом сама система качества должна содержать формы для "раскрутки" спирали коллективного знания:

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

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

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

КОМПЬЮТЕРЫ НА ФИРМЕ – МЕСТА МНОГО НЕ ЗАНИМАЮТ, А ПРИМЕНЕНИЕ ВСЕГДА НАЙДЕТСЯ…

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

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

Компьютерная технология проходит на фирме несколько этапов развития (которые тесно связаны с развитием самой фирмы):

Приобретение первых десяти компьютеров. Традиционное возмущение руководителя на "непомерные" запросы "местного программиста" (он еще не скоро будет называться "Системный администратор"): "Какие еще программы? Я на тебя и так десять штук истратил. Работай как все: включай в сеть и жми на кнопки. И поменьше демонстрируй свою образованность". На этом этапе заказное программное обеспечение фирме не требуется.

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

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

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

Стоимость оплаченных систем на этом этапе редко превышает 500-2000 долларов. Это без сомнения рынок тиражируемых решений.

Автор, рискуя показаться снобом, не относит студенческие разработки на Access-е к заказным проектам. Такие программные продукты имеют низкую стоимость и очень короткий жизненный цикл. Они не оказывают сколько-нибудь существенное влияние на рынок информационных систем.

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

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

На рынке фирм третьего этапа развития, стандартные и заказные системы конкурируют друг с другом на паритетных условиях. Более того, зачастую бывает трудно провести точную классификацию данного конкретного проекта. Цены и тех и других решений, как это ни странно – примерно одинаковы. Иногда тиражируемые изделия обходятся дороже заказных, если считать стоимость всех работ и лицензий, а не рекламную цену одного рабочего клиентского места. Разброс цен – от 10000 до 100000 долларов на отечественные разработки и от 100000 до 1000000 на западные. При этом процент западных провальных проектов ничуть не ниже "наших".

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

Самый интересный этап развития заказчика. Ему мы посвящаем отдельную главу нашего повествования:

КОРПОРАТИВНЫЕ ИНФОРМАЦИОННЫЕ СИСТЕМЫ – "ХОРОШЕЕ МЕСТО" ДЛЯ НАКОПЛЕНИЯ КОЛЛЕКТИВНЫХ ЗНАНИЙБ

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

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

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

Например, объединить десятки филиалов по всей стране, так чтобы банки данных филиалов работали автономно, но в едином информационном поле, с ежедневным или ежечасным обменом данными (в технологии ЕМЕ-ДБ такие информационные каналы называются "Информационные трубки", а технология объединения данных - "Гребенчатая схема консолидации данных").

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

Оптимальное управление торгово-производственным объединением с применением методологии MRP-II.
Оптимальное планирование ресурсов и управление производственными процессами, тоже с применением MRP-II.
Логистика многоярусного гигантского склада с применением систем штрихового кодирования.
Логистика аэропортовского пассажирско-транспортного хозяйства и таможенного складского терминала.
Логистика грузовых транспортных потоков с задачей оптимального распределения товаров по региональным складам.

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

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

Необходимо обеспечить положительную динамику развития КИС, так чтобы она не отставала, а опережала развитие предприяития.

Это означает, что система должна постоянно дополняться организационными идеями в виде новых программных модулей.

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

Мы уже говорили, что система качества, как форма коллективного знания, не возникает вдруг. Она развивается вместе с предприятием, впитывая новые идеи, пробуя разные подходы. Это означает, что хорошую КИС нельзя купить, ее можно вырастить на своем предприятии. Вырастить с помощью надежного партнера – фирмой, изготавливающей программы на заказ.

МЕТАПРОЕКТ – РЕШЕНИЕ ФУНДАМЕНТАЛЬНОЙ ПРОБЛЕМЫ ЗАКАЗНЫХ ПРОЕКТОВ

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

В самом начале статьи мы обсуждали вопросы технологичности. И пришли к выводу, что заказные программы – это не технологично. И это действительно так. Нельзя думать, что, начав разрабатывать компьютерную систему "с кремниевого песка" (для изготовления микросхем), можно в конечный период времени создать что-нибудь работающее. Даже, если разработка ведется от уровня СУБД класса Oracle, объем прикладной части системы слишком велик для работы "с нуля". Кроме того, от программистов требуется обладание значительным опытом решения задач в конкретной прикладной области. Можно, конечно, создать в Excel-е таблицу под названием "Товарные остатки" и считать, что логистика товарного движения автоматизирована. Это то, что мы называем "функционально примитивное изделие".

Очень часто руководитель решает, что, создав отдел "информационных технологий" у себя на фирме, он "заплатит подороже, за то будет иметь все свое". В результате пять программистов в течение двух лет расходуют (с учетом накладных расходов) 150000 долларов и решают, что им пора увольняться. А руководитель остается "со всем своим".

Закон сохранения энергии в информатике можно сформулировать как закон "сохранения информации". Потеряв в технологичности на тиражировании изделий, мы должны скомпенсировать прилагаемые усилия, привнеся технологию в сам процесс производства заказных систем. Такая технология в России создана на фирме ЕМЕ. Эта технология называется "Метапроект".

Метапроект состоит из нескольких взаимодополняющих друг друга элементов:

  • Уникальное ядро СУБД ЕМЕ-ДБ позволяет совместить визуальное конструирование диалогов и отчетов с разработкой "чистых" (не связанных с конкретным проектом) алгоритмов на C++. СУБД – разработка фирмы ЕМЕ, обладает также уникальными характеристиками надежности, которые позволяют давать десятилетнюю (!) гарантию на целостность банка данных и работоспособность системы без резервного архивирования данных.
  • Оригинальное ноу-хау фирмы ЕМЕ, единый корпоративный интерфейс-стандарт "Метапроект", составленный из имен полей обобщенной структуры данных, имен диалогов и их органов, имен отчетов и их колонок (примерно десять тысяч позиций). Такой интерфейс, дополненный древовидной иерархической структурой и перекрестными связями, составляет вербальную модель внешнего мира, который когда-либо автоматизировался фирмой.
  • Программы-алгоритмы всех проектов концентрируются в Библиотеке Метапроекта. Программы представляют собой "чистые" алгоритмы, которые связываются с внешним миром только через интерфейс-стандарт Метапроекта и получают управление посредством событийно-ориентированной системы сигналов ядра СУБД.
  • Процесс производства программ на фирме ЕМЕ ведется по конвейерной схеме (см. рис.) с глубоким иерархическим разделением труда. На фирме строится собственная система качества, базирующаяся на корпоративной информационной системе с базой знаний.

Объем журнальной статьи не позволяет подробно рассказать о технологии "Метапроект". Коэффициент повторно используемого кода в нынешних проектах фирмы составляет 60-70 процентов. С каждым новым проектом этот показатель растет, мы рассчитываем довести его до 80-85 процентов. Таким образом, в соответствии с законом "сохранения информации" мы переносим тиражируемость программы с уровня целого изделия на уровень "чистых" алгоритмов Метапроекта. Опыт всех разработок "овеществляется" в виде библиотек алгоритмов и мы получаем возможность, точно балансируя на грани тиражируемое - специальное, обеспечивать нашим клиентам уникальные заказные проекты с действительно положительной динамикой развития.

С автором можно связаться по электронной почте eme@eme.ru.
Описание технологии "Метапроект" можно найти на сервере www.eme.ru.

Смотрите также…