CC BY
122
УДК 004.431.4
АВТОМАТИЗАЦИЯ РАБОЧИХ ПРОЦЕССОВ ПРЕДПРИЯТИЯ С ИСПОЛЬЗОВАНИЕМ COMINDWARE TRACKER
Трифонова Анна Александровна, студентка 5 курса, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]
Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]
Введение
Перед любым предприятием по мере его развития рано или поздно встает задача автоматизации управления бизнес-процессами. Решить эту задачу можно различными способами, каждый из которых будет иметь собственные преимущества и недостатки. Распространенным способом является создание решения на базе готовой программной платформы. Такой программной платформой могут послужить процессно-ориентированные системы, в частности workflow-системы, получившие распространение в последние несколько лет [1].
В данной статье рассматривается возможность автоматизации процесса выполнения заказа на полиграфическом производстве за счет создания решения в одной из существующих систем. В качестве такой системы была выбрана платформа Comindware Tracker [2]. Она представляет собой программное обеспечение для управления совместной работой, которое позволяет обеспечить коллективную работу различных отделов и команд. Система позволяет в визуальной среде создавать, автоматизировать и оптимизировать процессы, организовывать управление объектами (запросами, требованиями, заказами и др.), автоматически назначать задачи сотрудникам.
1. Постановка задачи
Пусть имеется следующая задача. На полиграфическом предприятии процесс формирования и выполнения заказа происходит следующим образом:
• клиент описывает заказ менеджеру;
• менеджер составляет паспорт заказа, содержащий следующую информацию: данные о заказчике, сроках выполнения, используемых материалах, технологиях, описание наносимых изображений и их цветность, данные о макетах и шаблонах, расчет стоимости единичного изделия и тиража, а также данные менеджера, принимавшего заказ;
• копия паспорта заказа отдается дизайнеру, разрабатывающему изображение и (или) макет;
• после создания макета и утверждения его заказчиком паспорт заказа передается инженеру по фотовыводу, который занимается подготовкой фотоформ;
• после того, как фотоформы подготовлены и проверены на корректность, паспорт заказа передается мастеру цеха;
• мастер цеха, основываясь на данных имеющихся у него на текущий момент паспортов, распределяет задания между работниками цеха (шаблонщиками, печатниками и работниками, отвечающими за дополнительные операции);
• после выполнения задания работником в паспорте делается пометка о выполнении заказа и он передается менеджеру;
• заказчик оплачивает заказ (если им не была осуществлена 100%-ая предоплата) и забирает готовые изделия.
В настоящий момент основным инструментом согласования действий между сотрудниками, участвующими в процессе выполнения заказа, является паспорт заказа, а именно, его бумажная копия. Передача необходимой для работы информации в таком виде
55
увеличивает временные издержки при информационном обмене между участниками процесса. В некоторых случаях такие задержки являются критичными - например, важные изменения в условиях заказа, оперативно не донесенные до непосредственных его исполнителей, может привести к браку большого тиража продукции, а, следовательно, к убыткам для фирмы.
Как отмечено в работе [3], такая проблема может быть связана с применением функционального подхода к управлению на предприятии. Внедрение решения, ориентированного на бизнес-процессы, а также обладающего гибкостью в плане изменения этих процессов, может стать толчком к переходу к процессному управлению. Кроме того, если предлагаемое решение будет достаточно простым, то предприятие сможет оперативно модифицировать его в соответствии с меняющимися требованиями бизнеса без привлечения внешних специалистов. Это, в свою очередь согласно выводам работы [4], снижает риск обособленности системы автоматизации от бизнес-процессов организации.
Таким образом, перед нами встает задача управления процессом выполнения заказа. Неэффективное управление может привести предприятие к потерям времени, заказов и прибыли. Поэтому важно, чтобы создаваемое решение предусматривало различные способы создания отчетности, позволяющей оперативно выявлять «узкие» места процесса. Разрабатываемое решение должно помочь усовершенствовать процесс оформления и обработки заказов за счет упрощения процессов согласования на каждом этапе выполнения заказа и снижения временных издержек, возникающих при передаче бумажной копии паспорта от одного участника процесса к другому. Кроме того, мы предполагаем, что такое решение предприятие может создать самостоятельно на базе готовой системы, без привлечения внешних специалистов.
На первом этапе работы над задачей нами был проведен анализ предметной области и существующих в ней бизнес-процессов. На втором этапе на основе описанного бизнеспроцесса мы попытались создать работоспособное решение, удовлетворяющее требованиям заказчика, в системе Comindware Tracker. С результатами работы мы готовы ознакомить читателей в настоящей статье.
2. Предлагаемое решение
Система Comindware Tracker оперирует такими понятиями, как шаблон, рабочий процесс, группа и рабочая область, поэтому далее приведено их краткое освещение (рис. 1). Более подробную информацию можно найти в документации по системе [5].
Создание любого объекта в системе Comindware Tracker происходит на основе шаблона. Следовательно, то, как будет выглядеть объект и каким будет его поведение, зависит от настройки параметров шаблона. Она, в свою очередь, сводится к созданию полей шаблона (поля определяют информацию, которую будет нести в себе объект), настройке формы (форма определяет способ отображения полей шаблона) и настройке рабочего процесса (рабочий процесс определяет жизненный цикл созданного объекта). Поскольку нам важно не только создать заказ в системе в виде некоторого статичного документа, но и контролировать процесс его выполнения, то заложенная в системе концепция рабочих процессов представляется нам хорошим инструментом для достижения поставленных целей.
По сути, рабочий процесс представляет собой конечный автомат или диаграмму состояний, описывающую возможные последовательности переходов объекта из одного состояния в другое. В терминах системы Comindware Tracker состояние - это шаг, на котором находится объект в рабочем процессе. Для связи шагов и перемещения объекта с предыдущего шага на следующий используются переходы. Срабатывание перехода зависит не от выполнения определенных условий (исключается возможность проверить с помощью логического условия возможность перехода), а только от наступления события. Событием, инициирующим переход объекта, может являться задача (также возможен «ручной» перевод объекта на следующий шаг). Задача выступает в качестве поручения для какого-либо сотрудника и закрепляет ответственность за выполнение им некоторой работы. В свою
56
очередь задача, как и объект, может переходить из одного состояния в другое. Разница здесь состоит в том, что в системе для задач существует заданный набор состояний и изменить его нельзя.
Рис. 1 - Структурная модель понятий системы Comindware Tracker
Для объединения однотипных объектов (созданных на основе одного шаблона) существуют группы. Также группы позволяют настроить набор разрешенных действий (уровни доступа) для пользователей и групп пользователей.
Созданную группу можно добавить в рабочую область. Рабочая область представляет собой объединение групп задач и объектов, совместно используемых группами пользователей. С помощью рабочей области можно создавать отдельные рабочие среды для различных отделов или проектов в рамках организации. Несомненным плюсом является то, что вместе с системой поставляются примеры настроенных рабочих областей, включающих в себя готовые шаблоны, рабочие процессы и группы объектов. Это позволяет быстрее освоить принципы работы с системой и упрощает процесс ее настройки.
Сформировав некоторое представление об основных идеях, заложенных в Comindware Tracker, мы попытались настроить систему в соответствии с условиями поставленной задачи.
Как было сказано выше, основным источником информации для ответственных за выполнение заказа лиц является паспорт заказа. Поэтому было решено создать шаблон для заказа, которого было бы достаточно для занесения в систему всей той информации, что несет в себе паспорт заказа. В результате для шаблона были созданы поля, содержащие информацию о заказчике, об особенностях заказа и его стоимости.
Настройка шаблона, прежде всего, предполагает создание необходимых полей. Система Comindware Tracker содержит большой список системных полей, которые мы можем использовать по умолчанию, и, как показывает практика, иногда этого вполне достаточно - в общем случае любому объекту необходимы такие поля как, например, идентификатор или описание. Также полезным оказалось наличие такого системного поля как "Создан" - с его помощью мы всегда сможем идентифицировать менеджера, добавившего заказ в систему.
Для того чтобы отразить особенности предметной области, нами были созданы собственные поля согласно модели паспорта заказа, представленной на рис. 2. Система
57
позволяет работать с различными типами полей (более подробно о них можно узнать в документации по системе). По большей части нами использовались такие типы полей как текстовое, числовое, а также список значений.
Рис. 2 - Диаграмма классов паспорта заказа
Список значений был применен для фиксированных наборов значений (например, набор возможных форм оплаты - взаимозачет, предоплата) и в качестве замены полей булевского типа, которые система не поддерживает. Неудобства также вызвало отсутствие возможности использования чисел с плавающей запятой. Comindware Tracker предоставляет собственный язык выражений для вычисления значений полей. В формулах используется содержимое других полей, поэтому нам показалось логичным попробовать применить такую возможность для вычисления цены тиража или площади изображения. Но, как было сказано выше, в системе отсутствует тип, поддерживающий дробные числа (а именно такой может быть цена со скидкой или площадь изображения), поэтому в этом случае от использования вычислимых полей пришлось отказаться.
Тем не менее, вычислимые поля все же нашли применение в нашем решении. На практике часто возникает ситуация, что клиент обращается в организацию более одного раза и, следовательно, нет необходимости вторично заносить в систему уже имеющиеся в ней данные о клиенте. Поэтому был создан шаблон объекта "Заказчик", содержащий в себе все необходимые поля с информацией о нем (адрес, контактное лицо, телефоны и т.д.). В шаблоне объекта для заказа были созданы поле "Заказчик" с типом "Ссылочное" (оно ссылается на объект "Заказчик") и поля, аналогичные используемым в шаблоне "Заказчик", только с заданным свойством "Вычисляемое" и некоторым выражением поля. Таким образом, если при создании заказа в поле "Заказчик" будет выбрано значение из списка занесенных в систему, то настроенные поля заполнятся автоматически после сохранения заказа. Такое поведение системы, несомненно, облегчает работу менеджеров при приеме заказов от постоянных клиентов.
Система Comindware Tracker обладает развитыми средствами для настройки формы ввода информации об объекте. Поэтому, когда созданы все необходимые поля, редактирование формы не представляет особой сложности - нужно просто добавить поля на форму (это делается перетаскиванием их мышью) и разместить их так, как мы считаем нужным.
58
Заказ обладает ясно выраженным жизненным циклом, который мы можем описать посредством рабочего процесса. Как уже было сказано, в рассматриваемой нами организации имеет место ситуация повторного обращения клиентов. Однако, существуют и другие условия, при воссоздании которых изменится рабочий процесс (например, у клиента есть готовый макет, следовательно, услуги дизайнера ему не требуются; клиент хочет заказать дополнительный тираж, следовательно, можно сразу перейти к непосредственному выполнению заказа без предпечатной подготовки). Для таких ситуаций мы решили создать дополнительные шаблоны и, следовательно, рабочие процессы, отличающиеся друг от друга отсутствием определенных стадий предпечатной подготовки (рис. 3).
Рис. 3 - Модель подпроцесса “Предпечатная подготовка”
В результате мы получили 4 шаблона рабочих объектов, реализующих собой 4 возможных варианта заказа: "типичный" заказ, которому необходимы все три стадии предпечатной подготовки (разработка дизайна, изготовление фотоформы, изготовление шаблона) (схема рабочего процесса представлена на рис.4); заказ без дизайна; заказ без фотовывода; заказ без шаблона.
Для автоматического создания задач работникам в процессе выполнения заказа было настроено автоматическое создание задач при переходе объекта на любой шаг, кроме начального и конечного. Как говорилось ранее, задачи создаются для закрепления ответственности за определенный шаг за сотрудником. С одной стороны, если у нас по одному пользователю для каждой имеющейся роли, то мы просто укажем конкретного пользователя, для которого будет создаваться задача. Но с другой стороны такая ситуация далека от реальности, поэтому мы решили проблему следующим образом - задача назначается определенному пользователю, который выступает в роли руководителя (у дизайнеров это может быть, например, главный дизайнер, в цехе это мастер цеха и т.д.), и уже он переадресует эту задачу своему подчиненному. Возможно, что такая схема в реальности покажется малоэффективной, но следует понимать, что у любой системы могут быть свои нюансы, под которые придется подстраиваться.
Рассматриваемое нами в качестве примера полиграфическое производство, как и любое другое предприятие, обладает некой организационной структурой. Ответственность за тот или иной участок процесса закреплена за людьми с определенными должностями, и важно учесть этот факт при настройке системы. В соответствии с ролями, исполняемыми работниками организации в процессе выполнения заказа, было выделено 5 групп
59
пользователей: менеджеры, дизайнеры, инженеры по фотовыводу, мастера цеха, работники цеха. Также для того, чтобы логически разделить непосредственных исполнителей заказа (работников цеха) и работников, занимающихся работой с клиентами и предпечатной подготовкой, были созданы две рабочие области - "Офис" и "Цех".
Естественно, что нам необходимо не только разделение пользователей на определенные категории, но и назначение им определенных привилегий и ограничений. Например, работнику цеха не нужна возможность создавать заказ в системе, т.к. созданием заказов занимаются только менеджеры. Такие и подобные ограничения мы реализовали путем настройки уровней доступа к группам объектов, а также добавлением группы объектов к нужной рабочей области (это необходимо для отображения групп). Для того чтобы реализовать описанное выше ограничение, мы установили уровень доступа "Участники" к группам объектов, связанных с шаблонами для создания заказа, для группы пользователей "Менеджеры" и добавили группы объектов к рабочей области "Офис". Это значит, что все пользователи, входящие в группу "Менеджеры", смогут создавать, изменять и просматривать заказы. Поскольку для группы "Работники цеха" мы не устанавливали уровней доступа, то члены этой группы не смогут создавать и изменять заказы. При этом работники могут выполнять задачи в рамках рабочего процесса и, таким образом, переводить заказ из одного состояния в другое.
Для получения оперативной информации о движении заказа и текущей стадии его выполнения нам необходимо использование различных отчетов. Система Comindware Tracker предлагает два способа их реализации: в виде списков, позволяющих группировать объекты или задачи по определенным критериям, а также в виде панелей мониторинга, представляющих собой набор настраиваемых диаграмм и графиков (виджет в терминах системы) для отображения информации в удобном графическом представлении. Списки и панели мониторинга могут быть как доступными только пользователю, создавшему их, так и общими. Это позволяет один раз настроить необходимые отчеты и предоставлять к ним доступ определенным пользователям.
Был создан список «Все заказы», агрегирующий в себя заказы, созданные по 4 настроенным шаблонам; он доступен только тем группам пользователей, которое имеют разрешение на просмотр заказов в соответствующих группах объектов. Такой несложный отчет позволяет менеджерам увидеть, на какой стадии выполнения находится тот или иной заказ, кто ответственен за его выполнение на этой стадии, а также насколько быстро выполняются отдельные заказы и заказы в целом.
Виджеты создаются на основе списков. Каждый виджет может содержать данные из одного или нескольких списков. Для отображения актуальной информации об имеющихся заказах, а также о выполнении заказов конкретных заказчиков была создана панель мониторинга «Статистика по заказам», содержащая два виджета - круговую диаграмму «Все заказы по состояниям» и линейчатую диаграмму «Состояние заказов (по заказчикам)». Обе диаграммы строятся на основе данных из созданного нами ранее списка «Все заказы» и фактически представляют собой удобный способ отображения необходимой менеджерам и руководителям информации.
Выводы
Таким образом, высказанное нами ранее предположение о возможности создания полноценного рабочего автоматизированного решения без привлечения внешних специалистов во многом подтвердилось. Создание нового решения или адаптация имеющегося в Comindware Tracker не вызывает особых трудностей. Но, сталкиваясь с простотой и доступностью использования готовой системы, приходится жертвовать сложностью реального процесса и идти на определенные допущения.
Литература
1. А. Резниченко. Системы workflow/BPM - проблемы роста // PCWeek/RE, № 29, 2005. URL: http://www.pcweek.ru/idea/article/detail.php?ID=70973 (дата обращения: 12.04.2013).
60
2. Приложение для управления совместной работой - Comindware [сайт]. URL:
http://www.comindware.com/ru (дата обращения: 12.04.2013).
3. Д. Пинаев. Процессное управление: в чем сила? // БОСС, № 3, 2012. URL:
http://www.bossmag.ru/archiv/2012/boss-03-2012-g/protsessnoe-upravlenie-v-chem-sila.html (дата обращения: 12.04.2013).
4. Ю. Вагнер. BPM без бизнеса // Открытые системы, № 2, 2012. URL:
http://www.osp.ru/os/2012/02/13014103 (дата обращения: 12.04.2013).
5. Руководство по продуктам Comindware [сайт]. URL:
http://www.comindware.com/ru/support/resources (дата обращения: 12.04.2013).
УДК 004.413
ФРЕЙМВОРК ИНТЕГРАЦИИ ПОИСКОВОЙ МАШИНЫ В ИНФОРМАЦИОННЫЕ
СИСТЕМЫ
Крылов Александр Юрьевич, студент, Ивановский государственный химико-технологический
университет, Россия, Иваново, [email protected] Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]
Любая современная информационная система (ИС) работает с большим количеством информационных ресурсов, которые представлены в виде баз данных, текстовых документов различного формата, электронных таблиц, адресных книг, профилей пользователей, лог-файлов, изображений, аудиофайлов и т. п.
С целью облегчения работы пользователей с системой, разработчики снабжают системы возможностями информационного поиска по используемому в ней контенту. При этом, как отмечено в работе [1], разные формы представления информационных ресурсов требуют организации различных форм поиска по ним.
Реализация поиска в современных ИС зачастую представляет собой отдельный функциональный модуль системы, направленный на решение данной задачи. Качество такого модуля во многом определяется результатами его работы: гибкостью, удобством, возможностями масштабирования, скоростью работы и т. д. С целью решения этих задач, разработчик прибегает к самостоятельной реализации таких модулей, которые, в свою очередь [2,3]:
• вынуждают разработчиков ИС повторно разрабатывать подсистему поиска (временные затраты) для каждой системы и типов документов;
• обладают низкой гибкостью и слабым функционалом, в силу того, что не являются основной целью разработки информационной системы;
• требуют технической поддержки и сопроводительной документации в течение всего процесса функционирования (эксплуатации);
• содержат различные ошибки в концепции, архитектуре или программной реализации;
• обладают недостаточной документацией;
• слабо стандартизированы;
• плохо пригодны к модификации, поскольку являются побочным результатом построения ИС.
Рассмотрев в качестве примера принципы функционирования документноориентированных систем [4], отметим, что реализация подсистемы поиска может представлять собой достаточно типичную задачу. Такое предположение рождает предпосылки того, что возможна некоторая стандартизация поисковых подсистем, их унификация.
В результате возможно создание некоторого универсального средства (инструмента), предназначенного для реализации поиска в целевой информационной системе, которое
61
