Сетевой журнал: галерея ИТ-проектов


DIGITAL MACHINES: ЭВОЛЮЦИЯ ИЛИ РЕВОЛЮЦИЯ?



задача:
Интеграция "лоскутной" КИС
другие решения:
ComputerAge : улучшить систему, а не бороться с ней
ЛАНИТ: ВЕА-платформа плюс адаптеры - и no problem





 

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

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

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

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

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

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

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

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

Рисунок

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

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

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

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

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

Интеграция и еще раз интеграция
На вопрос, каким образом будет осуществляться интеграция бизнес-процессов компании и бизнес-процессов ее крупнейших оптовых партнеров, т. е. обмен данными и их репликация, специалисты Digital Machines ответили следующее. В данном случае все будет зависеть от того, какие именно программные продукты применяются нашей гипотетической компанией и ее контрагентами и насколько интенсивный обмен данными им необходим. Если, например, у контрагента установлена та же самая система "1С: Бухгалерия", что и у нашей компании, обмен файлами может происходить непосредственно, а если системы разные, тогда возможны два варианта. Первый - организовать обмен данными через специальную программу MQ-Series, обеспечивающую передачу сообщений и синхронизацию данных. Второй, также вполне стандартный вариант - обмениваться данными через XML-формат, который поддерживается многими программами.

Таким образом, в первую очередь мы должны выяснить, что именно имеется у контрагентов и к какому решению они склоняются. В данном случае не столь важно, использовать ли MQ-Series (либо некий другой стандартный продукт), "затачивая" под него ПО нашего предприятия, или, скажем, "1С: Бухгалтерию" (в которой, кстати, есть свой конвертер и XML-формат). Главное - не забыть сначала обсудить это с партнерами. При решении вопроса об обмене данными многое будет зависеть от взаимопонимания между партнерами, их желания налаживать такой обмен и готовности тратить деньги на интеграцию.

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

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

Существенно уменьшает затраты на сопровождение применение генератора отчетов, собирающего нужные сведения из любых подсоединенных к нему баз данных. Здесь, так же как при описании и настройке бизнес-процессов, бизнес-аналитики могут действовать совершенно самостоятельно. Ни постановка задачи создания нового отчета, ни его написание и затем подключение к системе не требуют какого бы то ни было кодирования. Значит, исчезает необходимость задействовать для этого разработчиков, а кроме того, становятся не нужны дополнительные согласования между ними и бизнес-аналитиками. Если стандартной является двусоставная схема: бизнес-аналитик, формулирующий задачу, и разработчик, который ее реализует, - то здесь последнее звено отсутствует, поскольку бизнес-аналитик сам работает с генератором отчетов. Когда ему потребуются какие-то очень сложные вычисления, без участия программиста, конечно, не обойтись, но львиную долю несложной отчетности с помощью генератора отчетов он может получать быстро и просто, экономя, таким образом, время и деньги. Все оформление и все связи настраиваются визуальными средствами в стандартных офисных приложениях типа Excel, Word, можно получать отчеты также в текстовом формате или в html. Генератор отчетов практически не зависит от способа хранения данных (Oracle, Access), может работать с несколькими базами одновременно, получая информацию сразу из нескольких систем и отображая ее в нужном отчетном виде.

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

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

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

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

Все зафиксировано
Рядовой пользователь - работник предприятия о любой новой системе всегда может сказать, что она не работает или она работает не так. Воля руководства тут решает многое, но хорошо бы плюс к тому, как считают в Digital Machines, чтобы внедряемая система еще и позволяла каким-то образом документировать каждый шаг пользователей, поскольку нередко они начинают доказывать: "Система не работает, я там-то и там-то вчера сделал то-то и то-то, а сегодня я этого не вижу". Для разрешения конфликта важно иметь возможность показать, что, допустим, было сделано в 17 часов 15 минут и к чему в результате это привело. Когда пользователю пару раз докажут, что система работала правильно, а именно он или его товарищ поступили неадекватно, сопротивление гаснет само собой.

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

 
сетевой форум
архив
подписка на журнал
о сетевом

подписка на новости

подписка на журнал

архив номеров

архив новостей