Системы документооборота  -  копилка модулей, объектов, данных

 

Началось все с краткого разговора на Комтеке с Андреем Линевым, руководителем “ИнтерТраст Лтд”. “Опасность при разработке систем обработки документов,  -  сказал он,  -  заключается в попытках создания систем, интегрирующих все проблемы конкретной организации. Все это можно обозначить старым девизом "Строим АРМ". Несмотря на известный консерватизм, документооборот меняется  -  приходят новые люди, пересматривается процесс прохождения документов. Поэтому создание закрытых систем бесперспективно. Мы как бы даем клиенту "кубики" и рекомендации по их сборке. В основу построения каждого из комплектов ("Делопроизводство", "Внешние контакты", "Управление продажами" и т. д.), входящих в систему баз данных OfficeMedia, заложен принцип модульности. Комплект не является единой жесткой интегрированной системой, объединяющей все информационные процессы в рамках одной громоздкой базы данных организации, а представляет собой набор прикладных БД, работающих в единой среде Lotus Notes, которые могут использоваться как независимо друг от друга, так и в совокупности. При этом между отдельными базами данных возможен автоматический обмен документами”.

 

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

 

Евгений Веселов ( директор Дивизиона программных решений IBS):

 

Самое главное и в то же время наименее продвинутое в построении систем масштаба предприятия  -  это модель. Информационная, функциональная и иные модели отличают разработки такого масштаба от АРМов, созданных на Clipper, Fox (коих в стране  -  изобилие). Модели, вообще говоря, могут существовать и без CASE, но они обязательно должны выделяться и накапливаться. Когда я делал “Лексикон”, у меня образовалась совокупность модулей (типа вывода на печать и приема с клавиатуры), которые я использовал в дальнейшем. Теперь мы копим не столько программные модули, сколько модели существования, модели развития.

 

Мы много времени потратили на выбор CASE-системы. Начинали с легких средств типа DESIGN/IDEF, но они все же больше “рисовалки”, в них недостаточно поддерживается внутренняя целостность. В том же ERWin физическая модель от логической почти не отличается (между тем как логические сущности должны управляемо преобразовываться в структуры таблиц). Oracle Designer/2000  -  лидер, очень мощное, привлекательное средство для разработки, но оно ориентировано на работу в офисе. Наши же аналитики постоянно перемещаются, ездят на интервью к заказчикам с ноутбуками в другие города, некоторые проектировщики, консультанты работают дома, они не подключены к серверу. Поэтому для моделирования бизнес-процессов мы используем BPWin фирмы Logic Works, для информационного моделирования  -  S-Designor фирмы PowerSoft, интерфейсы же разрабатываются с применением PowerBuilder. Такая комбинация представляется компромиссной, мобильной и современной. (Что не мешает нам внимательно следить за развитием, например, SILVERRUN и JAM  -  они тоже вполне могли бы быть нашим выбором.)

 

CASE-средства абсолютно необходимы для проектирования информационных систем масштаба предприятия. Базу данных на 20 таблиц можно сделать и без CASE, но, когда сущностей под 2000, ни разработку, ни тем более поддержку системы без этих средств не осуществишь. Я сказал только о сущностях, в реальности же полная конструкция информационной системы включает не только информационное пространство, но и структуру бизнес-процессов, интерфейсов, проекцию всего этого на оргструктуру предприятия... Выбор системы программирования интерфейса  -  SQL Windows, PowerBuilder, JAM или Visual Basic  -  очень важен, ибо потом будет написано много кода, придуманы технологии сопряжения модулей, и вы надолго увязнете в инструменте. (Поэтому важно оценивать не только текущие возможности пакета, но и перспективы фирмы, динамику ее развития.) А вот в выборе Designer/2000, SILVERRUN или S-Designor для проектирования информационных моделей я особого драматизма не вижу. Мы с ERWin на S-Designor переключились за неделю, не понравится S-Designor  -  спокойно переключимся на что-то другое (файлы конвертируются).

 

У нас есть своя система автоматизации делопроизводства “Ирида” на платформе Lotus Notes. Сейчас концепции, заложенные в “Ириду”, переносятся на уровень открытых информационных моделей, их можно будет реализовать на Oracle или Microsoft SQL Server. Нашу концепцию мы называем “демо-поток”. Описание процессов на языке IDEFO (мы пользуемся его “подправленной” в сторону большего конструктивизма версией) затем передается некоему компилятору, который трассирует направление движения документов, связь их с рабочими местами, операциями и строит автоматизированную систему поддержки этого процесса. Таким образом автоматически порождается коллективный “органайзер”, который перемещает документы, доставляя их в нужные моменты нужным людям в нужном виде. После этого, естественно, пользователю захочется сделать следующий шаг, и к органайзеру, “демо-потоку”, будут постепенно добавляться модули, учитывающие содержание документов. Процесс внедрения системы в целом при этом будет более безболезненным.

 

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

 

Владимир Баласанян (генеральный директор фирмы “Электронные офисные системы”):

 

Мы занимаемся конкретными приложениями “под заказчика”. Такие области, как банковские системы, уже “разобраны” крупными фирмами, однако есть множество задач в малом бизнесе. Компьютеризировать его не слишком сложно, но мало кто этим занимается. Взялись мы, например, за автоматизацию деятельности туристической фирмы, туроператора. Это был консалтинг, закончившийся разработкой “под ключ”. Разработка велась на Microsoft Office, чтобы заказчик потом мог как можно дешевле приобрести все необходимое. Но в итоге выяснилось, что фирма не в состоянии оплатить даже себестоимость нашей разработки, а делать ее за свой счет при не очень большом числе туроператоров невыгодно. То же самое было со страховой медициной. Мелкий и средний бизнес еще не готов к большому количеству приложений, которые мы могли бы для него сделать.

 

Одна из немногих созревших ниш  -  это делопроизводство (документооборот  -  лишь часть его). Традиционно в государственных организациях существовали детальные, жестко регламентированные технологии работы с документами. Стандарты эти не есть достижения советской власти, они существуют в России со времен Сперанского. Мы (и в этом основная наша особенность), придерживаясь современной технологии workflow, очень четко выполняем все нормативные требования. Например, впервые в России создана и эксплуатируется единая информационная система комплексной автоматизации деятельности прокуратур “Надзор-95”. На основе отечественных стандартов и правил делопроизводства и с учетом нашего собственного многолетнего опыта разработана система автоматизации документооборота “Дело-96”.

 

Я убежден, что фирма, создающая прикладные программы, должна стараться вести разработки на базовом инструментальном средстве  -  языках 4GL или Visual Basic. Как только я начинаю использовать проблемно-ориентированное средство, я сразу что-то теряю, я вынужден становиться дилером Lotus, пропагандистом его приемов и решений, у меня снижаются инструментальные возможности. Я  -  независимый разработчик приложений. Если появится крупный заказчик, который скажет: “Все, что вы сделали, перепишите для меня под Lotus Notes”,  -  мы это сделаем.

 

Когда мы начинали, “Стиплер” попросил автоматизировать его, кстати чрезвычайно сложную, торговую деятельность. Сегодня система уже функционирует, по ней можно получить любую информацию: сколько продукции продано в течение сегодняшнего дня, прошлого месяца, сколько продал каждый сотрудник дилерского отдела.

 

Люди, с которыми мы работаем на этапе внедрения,  -  это руководители управлений делами общих отделов. Они  -  главные представители заказчика, они говорят, как строить экраны, какие параметры документов сохранять. Все их пожелания сводятся к одному  -  сократить или не сильно увеличить объем их работы. Между тем цель у системы другая: обеспечить контролируемость организации, знать, кто чем занимается в данный момент времени, как проходят документы. Под каждого клиента мы свой пакет “ломаем”, надстраиваем и “навязываем бантики”. Одно дело  -  купить компьютер, другое  -  заказать НИОКР. Не дозрел корпоративный менеджмент до корпоративных технологий.

 

Когда мне говорят, что под конкретную программу (некую R/3) перестроят деятельность всей компании, перекроят отделы, наймут других людей, я в это не верю. Да, мне (после ваших публикаций) звонили клиенты, интересующиеся реинжинирингом, но никто в России сегодня не готов вкладывать деньги в ломку своих структур  -  отдача-то будет не раньше, чем через год-два. Может быть, такие люди и есть, но мне они не встречались. Поэтому единственный путь  -  продажа монофункциональных систем, “подстроенных” под желания заказчика (в предположении, что система ценностей клиента уже сформировалась).

 

Я очень люблю компьютерную прессу, но она подчас “пудрит” клиентам мозги. Когда приходишь к заказчику и предлагаешь свой пакет, следует вопрос: “А он сделан на Lotus Notes?” А мне все равно, на чем что написано. Самое ценное в наших системах (при условии, что они работают на программно-аппаратной базовой среде у клиента)  -  это функциональные свойства. Мы раз в полгода проводим модернизацию, у нас есть договоры с 5-летней гарантией. На Западе до сих пор продаются DOS-системы управления предприятием, потому что многие организации еще не перешли на Windows, и ясно, что если они и будут переходить, то на Windows NT, а не на Windows 95. Глубочайшее заблуждение: если на некоем средстве, скажем Exchange, стоит метка “новинка”, то все приложения должны быть написаны на нем. А еще заказчики часто хотят получить исходные коды. Нам не жалко, но это иллюзия, что систему, на которой будет работать 100 человек, можно ежедневно переделывать, добавляя поля.

 

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

 

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

 

Александр Тепляков (менеджер ArgusSoft Company):

 

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

 

Методология STRADIS, о которой вы не раз упоминали в своих материалах, была и остается одной из мощнейших методологий разработки информационных систем. Но она все же имеет больше теоретический характер. Первый курс, который читается в нашем Учебном центре (“Аналитические методы программной инженерии”), связан как раз с методологией STRADIS. Однако рынок развивается, и ему нужны коммерческие продукты. Пользователь нуждается не в красивой методологии, а в системе, максимально точно отражающей его конкретный бизнес.

 

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

 

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

 

Причем консалтинг может выступать здесь в разных ипостасях. Если заказчик еще не представляет, с какой стороны ему подойти к автоматизации, на первый план выходит консалтинг бизнес-деятельности. Опыт обследования таких крупных организаций, как РАО “Газпром”, с использованием предлагаемого нами инструментария показал необходимость доработки известных методологий под особенности российского рынка. Другая ситуация  -  когда у клиента уже есть информационная система, она работает, но нуждается в модификации, в переходе на новую платформу. Здесь иная схема работы  -  пилотное проектирование, консалтинг, сопровождение.

 

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

 

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

 

Игорь Альтшулер

 

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

 

Владимир Баласанян

Версия для печати