Автоматизация хаоса, или Записки консультанта

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

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

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

Ты скажи, че те надо...

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

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

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

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

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

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

Предельным выражением этой функции является технологии WorkFlow, когда система наделяется знанием не только о том, что должно быть сделано, но и кем и в какой последовательности... Правда, в условиях "хаоса" WorkFlow умирает первой, и в реальной российской жизни эта технология мало применима.

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

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

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

Бухгалтер, милый мой бухгалтер...

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

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

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

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

Различия управленческого и бухгалтерского учета

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

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

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

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

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

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

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

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

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

Покажи мне свои данные, и я скажу, что тебе надо

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

Этот подход, сложившийся на Западе в 70-е годы, успешно применялся для автоматизации больших консервативных корпораций, работающих в стабильных условиях. Более того, на том уровне развития инструментария, когда любой элемент пользовательского интерфейса и любой запрос к данным нуждался в кропотливом и трудоемком программировании, иначе действовать, вероятно, было нельзя. Но с тех пор изменилось довольно многое. Жизнь стала гораздо более динамичной. Разработки, длящиеся год и более, что было нормальным явлением в 70-80-е годы, в современных условиях недопустимы. Вырос уровень инструментальных средств. Все современные CASE- и RAD-средства давно перешагнули уровень "языков 4-го поколения". Реляционные СУБД кардинально упростили реализацию запросов к данным. Фактически, все современные системы являются именно макетами в понимании "быстрого прототипирования" 80-х.

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

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

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

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

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

Правда, реальные данные имеют, как правило, более сложную структуру, чем таблицы Excel или плоские файлы Notes. В "честной" модели предметной области появляется много разных типов объектов и отношений между ними, изменяющихся во времени. Поэтому требуются более сложные средства моделирования. В начале 80-х на реализацию подобной концепции стали претендовать реляционные СУБД. Очень популярны были декларации о "программирования без программиста", основанные на использовании реляционных моделей и QBE (Query By Example) в качестве среды для работы пользователя. Все оболочки популярных настольных систем (от dBase II до Access) разрабатывались именно исходя из этой парадигмы. Если вспомнить, так даже SQL создавался не как стандартный способ взаимодействия с серверами баз данных, а как язык запросов, ориентированный на неквалифицированного пользователя!

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

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

При таком подходе выясняется, что значительная часть содержательных операций может выполняться стандартными методами, не привязанными к специфике предметной области. Например, большинство поисков успешно реализуется вполне универсальным механизмом QBF (Query By Form - такой способ задания поисковых запросов, при котором пользователь вводит условия запроса непосредственно в полях форм просмотра/редактирования данных). А возможности настройки состава и порядка полей в таблицах в сочетании с QBF значительно уменьшают потребность в специально разработанных отчетах.

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

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

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

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

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

Автоматизируем учет

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

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

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

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

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

Отец реляционной алгебры Кодд в начале 90-х выдвинул новую идеологию, названную им OLAP (On-Line Analytical Proceeding). Моделью данных для поддержки OLAP является многомерный куб, где на измерениях определены некоторые иерархии, а в клетках этого куба находятся числовые значения.

Например, динамика рынка ценных бумаг хорошо описывается измерениями Инструменты, Торговые площадки, Дата-время и Параметр (цена спроса, цена предложения, цена последней сделки, объем и др.), а значение параметра находится на пересечении этих измерений. Единичный факт (точка) выглядит, например, как "обыкновенные акции "Мосэнерго" на РТС имели 8 августа 1998 года в 15:00:00 bid (цену покупки) 1 цент".

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

Имеется класс программ для поддержки такой работы с данными. Они обычно используются для создания так называемых хранилищ данных. Самый известный у нас в стране программный продукт этого класса - Oracle Express Server.

Имеется также вариант этого подхода, называемый ROLAP (Relational OLAP), когда данные хранятся в реляционных базах данных, а работа с ними идет в OLAP-методологии и интерфейсе. Более того, последние версии SQL-серверов, например Oracle8i, содержат специальную поддержку характерных для OLAP способов организации данных, за счет чего их производительность на OLAP-задачах приближается к производительности специализированных хранилищ данных.

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

Внедрение

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

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

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

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

Заключение

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

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