Автоматизация деятельности предприятия и Open Source

Юрий Рашковский

1   Введение

[ Слайд 1 ]

Сейчас в Украине и России ситуация на рынках все больше и больше приближается к ситуации на рынках западных стран - ситуация жесткой конкуренции. Если еще 5-7 лет назад часто встречались сделки с рентабельностью в 100 и выше процентов, то сейчас это огромная редкость. В результате перед нашими предприятиями встали те же задачи, которые стоят и перед зарубежными компаниями - снижение цены продукции (за счет снижения себестоимости), более быстрые изменения бизнес процессов при изменении ситуации на рынке, повышение качества товаров и услуг. При этом услуги становятся более весомым компонентом и приобретают все большую значимость - очень часто конкуренция разворачивается именно в сфере сопутствующих услуг (сервисное обслуживание, скорость гарантийного ремонта и так далее). Для повышения качества ключевым моментом является индивидуализация предоставляемых товаров и услуг - каждый покупатель получает именно то, что он хочет, а не некий стандартный набор рассчитанный на среднего покупателя. Как пример -- сейчас я не знаю ни одной фирмы - продавца компьютерной техники, которая не собрала бы хотя бы один экземпляр компьютера полностью исходя из требований заказчика за такую же или чуть выше цену, как и стандартная конфигурация. А еще лет 10-20 назад, когда создавались первые экземпляры современных систем автоматизации, подобное положение вещей рассматривалось скорее как исключение, а не как правило. Такое же положение начинает складываться и в других отраслях. У каждой фирмы всегда были любимые клиенты, для которых были доступны специальные скидки, отсрочки платежа, условия поставки и так далее, так как эти клиенты приносили основную часть прибыли фирме. Но сейчас подобные услуги предоставляются уже и менее прибыльным клиентам, поэтому встает вопрос о снижении себестоимости предоставления индивидуализированных услуг, и главную роль здесь должны сыграть системы автоматизации.

2   Требования к современной системе автоматизации деятельности предприятия

[ Слайд 2 ] Для того, чтобы говорить о системах автоматизации деятельности предприятия, мы должны сформировать некоторые требования, которые должны к ним предъявляться.

2.1   Обеспечение индивидуализации

Обеспечение индивидуализированной работы с поставщиками и покупателями подразумевает:

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

2.2   Автоматизация рутинных процессов

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

2.3   Масштабируемость

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

2.4   Возможность плавного наращивания функциональности

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

Также нужно предусмотреть возможность легкого перехода на более поздние версии продукта с сохранением сделанных ранее индивидуальных настроек.

2.5   Невысокая "совокупная стоимость владения"

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

2.6   Безопасность

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

2.7   Интеграция служб

[ Слайд 3 ]

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

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

3   Преимущества Open Source для системы автоматизации деятельности предприятия

[ Слайд 4 ] Чем же хорош Open Source для системы автоматизации деятельности предприятия? Так как система предназначена для корпоративного пользователя, то здесь играют важную роль следующие факторы:

4   Что мы собираемся создать

E/AS не является конкурентом современных пакетов автоматизации деятельности, выросших из бухгалтерских программ и баз данных по складу. (типичный пример - 1С Предприятие) Все подобные программы рассчитаны в основном на ручной ввод информации и обработку данных в интерактивном режиме.

Главная задача E/AS - автоматизация бизнес-процессов предприятия. Как частный, но очень весомый случай - автоматизация документооборота между предприятиями. Система регистрирует события и самостоятельно производит необходимые ответные действия (пополняет запасы товара, например) без участия человека.

Также E/AS является хранилищем данных со сложной и неоднородной структурой и системой связей в удобной для человеческого мышления форме - объекты, группы объектов, связи между ними.

5   Проект E/AS

5.1   Предпосылки, история

В 2001-м году начинался русский проект FinLin, во главе которого стоял Андрей Черепанов. Изначально проект позиционировался как замена 1C для ОС Linux, то есть свободная система финансового учета.

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

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

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

5.2   Архитектура

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

5.2.1   Базовые понятия

[ Слайд 5 ]

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

Обьект

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

Идентификатор обьекта

Идентификатор обьекта OID - это адрес обьекта в виде 128-битного числа, которое состоит из двух 64-битных частей, первая из которых так называемый "виртуальный" адрес, который адресует контейнер объекта (репозиторий бизнес-объектов, репозиторий электронных писем, и так далее), а вторая - так называемый "физический" адрес, который адресует конкретный объект внутрии указанного контейнера.

Этот подход позволяет нам адресовать достаточно большое количество возможных объектов простым способом.

5.2.2   Общая система передачи данных и инвокации элементов бизнес-логики

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

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

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

5.2.3   Система бизнес-объектов

[ Слайд 6 ]

Одна из важнейших подсистем проекта - система бизнес-объектов. Бизнес-объект - это почти тот же самый объект, как его понимают в распространенных объектных и объектно-ориентированных языках. Вот основные отличия нашего бизнес-объекта:

Более подробные сведения и остальные отличия мы планируем опубликовать в документации к проекту, которая находится сейчас в стадии написания.

Бизнес-объект и его атрибуты тесно интегрированы в схему понятий нашей системы. Так, и бизнес-объект и его атрибуты имеют свои собственны OID'ы.

5.3   Используемые технологии

[ Слайд 8 ]

В качестве основного языка реализации мы взяли язык Objective Caml, пока еще мало известный на пост-советском пронстранстве. Этот функциональный язык, разработанный группой специалистов во Франции, был выбран благодаря следующим его параметрам:

В качестве основного же хранилища мы отказались от идеи использовать реляционные СУБД. Это был аргументировано тем, что в связи со своей природой, реляционные СУБД мало подходят для систем такого класса. Мы выбрали Berkeley DB как основное хранилище данных внутри системы, благодаря ее компактности, скорости и надежности.

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

Для разграничения доступа мы выбрали GSS-совместимую систему Kerberos, которая, надеюсь, в представлении не нуждается. Вообще говоря, теоретически возможно будет заменить Kerberos на другую GSS-систему, например, SESAME, если в этом будет необходимость.

5.4   Состояние проекта, планы

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

Мы представляем развитие проекта по такому плану:

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

На данный момент намм неизвестно ни одного подобного решения для SME, хотя спрос на такие решения существует.

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

6   Заготовленные Q&A

6.1   Почему не используется реляционная СУБД?

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

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

Далее, ссылки на внешние базы данных у реляционных СУБД реализуются из рук вон плохо. Также невозможно создать адекватный механизм индексации (например кластерный индекс по 6ти таблицам).

Администрирование распределенной реляционной базы также не очень простая и очевидная задача; достаточно будет посмотреть на схему, а потом представить выпадение одного из серверов. Навигация же по типам объектов, протоколам, версиям и метаинформации -- относительно легко воспринимается, потому как и мы мыслим похоже (фреймы Мински), кроме того, в объектной базе данных можно работать и с куском схемы вполне комфортно, а сам код такого инспектора высокоунифицируем и будет годиться для самых разнообразных типов объектов.

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

6.2   Почему не используется CORBA?

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

6.3   Почему Objective Caml а не ...?

Язык Objective Caml выбран в качестве основного языка разработки проекта, так как он удовлетворяет следующим требованиям:

6.4   Какие языки программирования планируется поддерживать?

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

В принципе, этот список - всего лишь начало и он может (и я думаю, будет) расширяться.

This document was translated from LATEX by HEVEA.