Применение платформы IBM FileNet P8 для ускорения разработки новой продукции

На практическом примере демонстрируется, как компания по производству потребительских товаров может применить платформу IBM FileNet P8 для ускорения вывода на рынок своей новой продукции

Концепция NPDI (New Product Development and Introduction – Разработка и вывод на рынок новой продукции) составляет важнейшую часть стратегии роста для компаний по производству потребительских товаров. Этот процесс в сильной степени зависит от контента и от установленных предельных сроков. В предлагаемой статье описывается, как платформа IBM® FileNet® P8 может быть с успехом использована для реализации одного из подпроцессов NPDI - Artwork Change Management (Управление изменениями изобразительных материалов). В статье подробно описываются следующие составные части примера реализации: создание потока процесса, использование электронной формы eForm для запуска потока процесса и построение Web-интерфейса с помощью ECM-виджетов (ECM или Enterprise Content Management – управление корпоративным контентом). Кроме того, в статье описываются две другие задачи, которые требуются для рассматриваемого решения: обеспечение обзора невыполненных запросов и реализация специального процесса рассмотрения. Цель статьи состоит в том, чтобы объяснить читателю, как объединить элементы портфеля ECM-продуктов для реализации своих собственных решений.

Джефф Дуглас, специалист по отраслевым решениям, направление Enterprise Content Management, IBM

Джефф ДугласДжефф Дуглас (Jeff Douglas) является сотрудником группы отраслевых решений, входящей в состав направления Enterprise Content Management корпорации IBM. В настоящее время основным направлением его деятельности является интеграция портфеля ECM-продуктов в стратегические решения для различных отраслей. Д. Дуглас является сотрудником IBM уже более пяти лет, а вопросами управления информацией он занимается на протяжении 17 лет.



30.11.2011

Введение

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

Платформа IBM FileNet P8 сочетает возможности по управлению контентом и управлению процессами, благодаря чему она способна служить надежным фундаментом для эффективной реализации NPDI-процессов (NPDI или New Product Development and Introduction – Разработка и вывод на рынок новой продукции). Кроме того, платформа FileNet P8 способна поддержать и другие важные функции, такие как обеспечение соответствия нормативным требованиям и интеллектуальный анализ операций в рамках бизнес-процесса.

В данной статье описывается порядок реализации одной из частей NPDI-процесса: управление изменениями изобразительных материалов. Цель статьи состоит в том, чтобы объяснить читателю, как он сможет использовать различные компоненты платформы IBM FileNet P8 для создания собственных решений подобного типа. Основное внимание в этой статье уделяется следующим моментам: создание потока процесса, использование компонента eForm для запуска потока процесса, построение Web-интерфейса с помощью ECM-виджетов. Кроме того, в статье описываются две другие задачи, которые требуются для этого решения: обеспечение рассмотрения невыполненных запросов и реализация специального процесса рассмотрения. В разделе «Ресурсы» в конце статьи приведены ссылки на более детальные материалы по всему NPDI-процессу и по многочисленным достоинствам ECM-технологий.


Управление изменениями изобразительных материалов

В рамках NPDI-процесса подпроцесс Artwork Change Management занимается изменяемыми или создаваемыми заново изобразительными материалами, призванными поддержать предложение нового продукта. На рис. 1 показаны этапы и участники рассматриваемого процесса с соответствующим контентом.

Рисунок 1. Общая структура управления изменениями изобразительных материалов
Рисунок 1. Общая структура управления изменениями изобразительных материалов

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

В последующих разделах данной статьи описывается пример реализации, созданный с помощью «готовых к применению» средств IBM FileNet P8. В данной статье предполагается, что читатели уже знакомы с компонентами платформы FileNet P8.

Продукты, использованные при разработке примера реализации

Весь пример был целиком создан с применением исключительно существующих компонентов программного пакета IBM FileNet P8:

  • В качестве репозитария контента использовался компонент P8 Content Engine 4.5.1.
  • Бизнес-процесс использует компонент P8 Business Process Manager 4.5.1.
  • Электронная форма была построена с помощью компонента FileNet P8 eForms 4.0.2.4.
  • Специализированные страницы пользовательского интерфейса были построены с помощью компонента ECM Widgets 4.5.1.
  • Поисковые возможности были реализованы с помощью компонента Workplace XT 1.1.4.

Создание инфраструктуры управления изменениями изобразительных материалов

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

Рисунок 2. Протекание процесса управления изменениями изобразительных материалов
Рисунок 2. Протекание процесса управления изменениями изобразительных материалов

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

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

Определение классов документов

В описываемом примере реализации инструмент Content Engine Enterprise Manager был использован для определения четырех классов документов. Первые три класса имеют критически важное значение с точки зрения управления изменениями изобразительных материалов:

  • NLI (Nutritional Label) – выпускается руководством группы исследований и разработок.
  • Die Line (Схема вырезания упаковки продукта) – выпускается Инженерно-конструкторской группой.
  • Artwork (Изобразительные материалы) – создается Группой художественного дизайна.

Каждый документ любого из вышеперечисленных классов использует такие системные свойства, как владелец и дата создания. Кроме того, могут быть добавлены некоторые дополнительные свойства, такие как case ID (идентификатор дела), material ID (идентификатор материала) и product ID (идентификатор продукта). Эти свойства обеспечивают гибкий поиск документов, что является важным требованием для данного решения. Идентификатор case ID важен потому, что он позволяет группировать все документы, связанные с определенным запросом на изменения. Это обеспечивает согласованный и полный контекст по мере протекания процесса между участниками, а также на входе/выходе различных систем.

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

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

Реализация бизнес-процесса

На рис. 3 показано протекание бизнес-процесса управления изменениями изобразительных материалов для рассматриваемого в данной статье примера реализации. Этот процесс был создан с помощью инструмента Process Designer.

Рисунок 3. Процесс управления изменениями изобразительных материалов
Рисунок 3. Процесс управления изменениями изобразительных материалов

Описываемый процесс очень прост. Некоторые пояснения о дизайне:

  • Все исходящие маршруты шага Case Setup имеют метку «all true conditions» (все условия истинны) для поддержки параллельной работы руководителей Инженерно-конструкторской группы и Группы исследований и разработок.
  • Деятельность группы художественного дизайна зависит от завершения работы в обеих вышеупомянутых группах. С целью реализации этого требования шаг Develop Artwork на закладке маршрутизации обозначен как collector step (объединяющий шаг). Шаг Corporate and Legal также обозначен как объединяющий. Это позволяет гарантировать, что все документы будут готовы к моменту окончательного утверждения.
  • Документы типа NLI (этикетка питательной ценности) и проектные документы могут подвергаться различным изменениям на протяжении описываемого процесса. В результате к процессу добавляются определенные шаги, призванные гарантировать наличие окончательных версий.
  • В рассматриваемом примере реализации Web-страницы пользовательского интерфейса были построены с помощью компонента ECM Widgets, что позволило участникам выполнять соответствующие шаги в описываемом процессе. Создание этих страниц более подробно описывается в последующих разделах данной статьи. После того как указанные страницы созданы, они связываются с нужным шагом посредством указания соответствующего обработчика шага (step processor) для этого шага и присвоения ему URL-адреса соответствующей страницы пользовательского интерфейса.

Существует несколько способов поручить конкретные шаги процесса определенному лицу или определенной должностной роли. Роли или лица могут быть приписаны к определенным рабочим группам. Кроме того, могут быть созданы личные почтовые ящики для входящей корреспонденции. В рассматриваемом примере для каждого шага процесса были созданы т.н. «очереди работников» (worker queue), которые затем были приписаны определенным должностным ролям. Эти очереди «питают» входящие почтовые ящики ролей, которым они были приписаны.

Предусмотрено несколько полей данных, которые могут быть заданы для каждого процесса. Так, в полях «attachments arrays» указываются прилагаемые документы типа Artwork, а в полях «attachment» указываются прилагаемые документы типа NLI и Die Line. Хотя в этих полях указываются отдельные вложения, они также могут быть включены в единый массив вложений. Помещение вложений в специальное поле облегчает их выделение в пользовательском интерфейсе.

В рамках описания данного процесса проектировщики могут встроить в него такие механизмы, как уведомления с помощью электронной почты, промежуточные пункты и точки эскалации, что позволяет гарантировать своевременное протекание процесса. Кроме того, процесс может иметь несколько пунктов для извлечения данных из системы операционной поддержки (SAP или IBM InfoSphere Master Data Management). К примеру, весьма вероятно, что информация будет извлечена из системы операционной поддержи для передачи документа NLI руководству Группу исследований и разработок. Кроме того, в конце процесса данные должны быть возвращены в систему операционной поддержи до момента завершения этого процесса. Поскольку рассматриваемый пример процесса построен в виде автономной реализации, подобная интеграция с системами операционной поддержи в нем не предусмотрена. Тем не менее это может быть легко сделано с помощью компонентного шага и нескольких специальных программных модулей.

Инициирование запроса на изменения изобразительных материалов с помощью компонента eForm

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

Рисунок 4. Запуск процесса с помощью электронной формы
Рисунок 4. Запуск процесса с помощью электронной формы

Руководитель службы маркетинга предоставляет символ UPC для соответствующего продукта. Затем этот символ UPC используется для заполнения большинства других полей в данной форме, включая поля Material Number (номер материала), Packaging Type (тип упаковки), Brand Code (код марки) и Project Number (номер проекта). Кроме того, по умолчанию предоставляются сведения об участниках процесса. Руководитель службы маркетинга может изменить эти сведения посредством выбора из списка участников.

Значения по умолчанию в соответствующих полях скорее всего будут извлечены из базы данных или из системы операционной поддержки с использованием символа UPC в качестве ключа. Электронная форма eForm поддерживает простой механизм конфигурирования по принципу «point and click», которые позволяет извлекать вышеуказанные значения с помощью различных коннекторов (JDBC-соединение или вызов Web-сервиса).

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

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

Просмотр невыполненных запросов на изменения

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

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

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

Документ запроса на изменения добавляется и поддерживается посредством соответствующих шагов в потоке процесса. Модифицированный порядок обработки показан на следующей схеме (см. рис. 5).

Рисунок 5. Отслеживание состояния запроса на изменения
Рисунок 5. Отслеживание состояния запроса на изменения

К процессу были добавлены шаги двух типов. Во-первых, сразу же после завершения запускающего шага (LaunchStep) был добавлен обработчик компонентного шага (component step), создающий документ запроса на изменения (этот шаг помечен на диаграмме как «Create request document»). В нижней половине снимка экрана показана конфигурация нового обработчика шага. Справа находятся параметры для функции createDocument компонента Content Engine (CE), которые используются для создания документа запроса на изменения. Имя документа для нового запроса на изменения задается в поле данных процесса с тем идентификатором CaseID, который был установлен на этапе запуска соответствующего запроса. Кроме того, ссылка на документ для нового запроса на изменения сохраняется в поле данных приложения с именем CaseTracker, благодаря чему к этому документу можно получить доступ на всем протяжении процесса. Все документы дела хранятся в папке репозитария, на которую ссылается поле данных приложения CaseFolder. Описываемый документ может иметь тип plain text или XML.

Для настройки свойств документа для нового дела используется параметр propArray. Формат этого параметра представляет собой серию кортежей следующего вида:

<property name, type, value>

Например, для установки начального состояния запроса на изменения задайте параметр propArray следующим образом:

"{'CaseState', 'STRING', CaseState}"

Третий аргумент в приведенном выше примере – это поле данных процесса с именем CaseState.

После того как документ запроса на изменения будет создан, в поток процесса могут быть вставлены дополнительные шаги для обновления этого документа запроса. Два таких шага показаны на рис. 5 – один после шага Generate NLI и один после шага Load Die Line. В рамках этих шагов (помеченных на схеме как Update Case State) функции setProperty могут использоваться для обновления свойств документа запроса на изменения (таких как состояние или уполномоченное лицо).

После создания всей инфраструктуры руководитель службы маркетинга может просматривать запросы на изменения с помощью специально созданной Web-страницы (см. рис. 6).

Рисунок 6. Пользовательский интерфейс для просмотра невыполненных запросов на изменения
Рисунок 6. Пользовательский интерфейс для просмотра невыполненных запросов на изменения

(Версия рисунка 6 в более крупном масштабе)

Показанный выше пользовательский интерфейс реализован с использованием виджетов, предлагаемых модулем ECM Widgets платформы IBM FileNet. Этот модуль представляет собой набор компонентов для пользовательского Web-интерфейса, которые можно связать друг с другом в специализированный пользовательский Web-интерфейс. На указанной странице имеется четыре виджета:

  • В верхней части страницы находится виджет типа Toolbar. Вы сможете использовать виджет Toolbar при создании ниспадающего меню специальных действий. С помощью панели Toolbar на этой странице руководитель службы маркетинга сможет инициировать новый запрос на изменения, который, в свою очередь, вызовет электронную форму (описанную выше и показанную на рис. 4).
  • Следующий виджет на этой странице – виджет типа Content List. Виджеты типа Content List демонстрируют результаты поисков в репозитарии. Они конфигурируются посредством предоставления URL-адреса сохраненной процедуры поиска, созданной с помощью инструмента Search Designer модуля Workplace XT. Виджет Content List на этой странице демонстрирует невыполненные запросы на изменения, порученные данному руководителю, а также важную информацию по каждому запросу (такую как состояние и уполномоченное лицо).
  • В левой нижней части страницы размещен еще один виджет типа Content List. Когда руководитель службы маркетинга выбирает какой-либо запрос на изменения из списка в верхней части страницы, выполняется поиск, после чего все документы, ассоциированные с этим запросом на изменения, отображаются в левом нижнем виджете. С помощью этого виджета руководитель службы маркетинга может просмотреть и отредактировать каждый документ.
  • В левой нижней части страницы размещен еще виджет Viewer. Виджет Viewer обращается к определенному документу и демонстрирует его содержимое. В описываемом приложении этот виджет берет документ запроса на изменения, выбранный в верхней части страницы, и показывает его содержимое, которое представляет собой дневник запроса на изменения. В настоящее время этот виджет работает в режиме «только чтение». Тем не менее можно создать специальный виджет, который позволит руководителю службы маркетинга вводить в дневник дополнительные комментарии.

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

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

В случае особых требований к связыванию вы можете воспользоваться «невизуальным» виджетом JavaScript Adapter, который позволяет написать код JavaScript для реализации специальных функциональных возможностей. В примере реализации этот виджет применяется для связывания верхнего виджета Content List с правым нижним виджетом Content List. JavaScript используется для передачи идентификатора CaseID из выбранной в верхнем виджете строки в нижний виджет, где он используется в качестве поискового ключа. Для реализации описанной выше функциональности достаточно добавить к странице виджет JavaScript Adapter и ввести в него следующий код JavaScript:

return [{'name':'CaseID', 'value':payload.name}]

В этом примере объект payload представляет контент, передаваемый из виджета Content List. Значение свойства с именем name присваивается параметру CaseID, который затем будет использоваться при поиске документов.

Затем необходимо связать друг с другом виджеты Content List, JavaScript Adapter и Document Viewer, как показано ниже на рис. 7, и скрыть виджет JavaScript Adapter, чтобы он не отображался в пользовательском интерфейсе.

Рисунок 7. Связывание двух виджетов друг с другом
Рисунок 7. Связывание двух виджетов друг с другом

Создание специальной рабочей среды с помощью виджетов

В рассматриваемом примере реализации каждый участник имеет свои уникальные обязанности. Хотя между этими обязанностями существует определенное перекрытие, мероприятия, в которых задействованы разные участники, непохожи друг на друга. В результате для выполнения своей работы с максимальной эффективностью каждому участнику необходима специально настроенная среда. В этом разделе статьи демонстрируется порядок использования модуля ECM Widgets платформы IBM FileNet для создания специально настроенной рабочей среды на основе Web-технологий.

На рис. 8 показана Web-страница рабочей среды для руководителя инженерно-конструкторской группы.

Рисунок 8. Основанная на Web-технологиях рабочая среда для руководителя инженерно-конструкторской группы
Рисунок 8. Основанная на Web-технологиях рабочая среда для руководителя инженерно-конструкторской группы

(Версия рисунка 8 в более крупном масштабе)

На этой странице имеется пять ECM-виджетов:

  • В верхней части страницы находится виджет In-basket, в котором демонстрируются все задачи, порученные данному инженеру.
  • Затем следует виджет Toolbar. Для инженерного персонала виджет Toolbar предлагает три опции: create a new teamroom (создать новое пространство групповой работы), conduct a document search (выполнить поиск документа), initiate a review process (инициировать процесс пересмотра). Добавление новых элементов к виджету Toolbar осуществляется посредством его конфигурирования и добавления новых пунктов меню. Пункты меню могут иметь различные типы. В данном примере все действия управляются URL-адресами, поэтому каждая опция меню конфигурируется с URL-адресом, который будет вызван при выборе этой опции.
  • Ниже виджета Toolbar размещен виджет Work Data, который демонстрирует все свойства выбранной задачи.
  • Справа находится виджет типа Attachment (помеченный как «Change Request Documents»), который показывает все приложения, ассоциированные с данной конкретной задачей. На снимке экрана также присутствует вложение для документа типа Line (инженер введет это вложение, когда оно будет готово) и вложение для плана проекта, соответствующего данному запросу на изменения.
  • Справа внизу расположен виджет Step Completion (помеченный как «Task Actions»). Этот виджет применяется для сохранения любых работ, выполненных в рамках определенной задачи, а также для присвоения задаче пометки «выполнено». После того как задача помечается как «выполненная», она удаляется из списка задач данного инженера.

Чтобы ассоциировать эту страницу с руководителем инженерно-конструкторской группы и сконфигурировать список задач с целью его демонстрации в виджете In-basket, выполните следующие шаги:

  1. 1. В консоли Process Configuration Console создайте область Application Space для предоставления необходимого контекста всем ECM-виджетам, которые являются частью вашего решения.
  2. 2. С помощью консоли Process Configuration Console задайте роль Engineering Role в пространстве Application Space и укажите данную страницу в качестве начальной страницы для этой роли.
  3. 3. При конфигурировании данной страницы с целью представления обработчика задачи, а также для ее использования в качестве начальной страницы, настройте виджет In-basket таким образом, чтобы он не открывал задачу в отдельном окне. К этому моменту вы уже указали данный URI-адрес для обработчика задачи, когда создавали поток процесса с помощью инструмента Process Designer.
  4. 4. С помощью консоли Process Configuration Console настройте виджет In-basket для роли Engineering Role на отображение очереди Engineering Work Queue, которая была создана при построении потока процесса. Для этого примера решения достаточно одного ECM-виджета In-basket для каждой из очередей Work Queue, которые были созданы и использованы при реализации потока процесса.

Описанные шаги должны быть выполнены для всех страниц, ассоциированных с определенными шагами в потоке процесса.

Создание возможностей для динамического рассмотрения

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

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

Рисунок 9. Запуск внутреннего процесса рассмотрения
Рисунок 9. Запуск внутреннего процесса рассмотрения

На рис. 9 показан применяемый по умолчанию экран WorkplaceXT для запуска потока процесса. Он демонстрирует поля данных для потока процесса и позволяет пользователю инициализировать их значения перед запуском.

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

Использование концепции process flow («поток процесса») для моделирования процесса рассмотрения позволяет автоматизировать этот процесс средствами ECM. Это помогает рационализировать проведение процессов, которые обычно выполняются вручную, что часто является источником неэффективности. Кроме того, поскольку процесс основан на ECM-технологиях, то после его завершения к дневнику запроса на изменения может быть добавлена соответствующая информация о лицах, рецензировавших данный документ. Эта информация может оказаться важной для ретроспективного анализа или для подтверждения нормативного соответствия.


Заключение

В статье были последовательно рассмотрены элементы примера реализации, демонстрирующие обширные возможности платформы IBM FileNet P8 в качестве фундамента для построения бизнес-процесса управления изменениями изобразительных материалов. Этот процесс составляет важную часть разработки новой продукции в отрасли потребительских товаров, а также в других отраслях, которые создают и поставляют какие-либо продукты. В статье излагаются технические подробности по выполнению таких задач, как создание потока процесса, использование электронной формы для запуска процесса и построение специализированных Web-страниц с помощью виджетов. Кроме того, в статье описываются две другие задачи, которые требуются для этого решения: обеспечение рассмотрения невыполненных запросов на изменения и реализация таких динамических процессов, как внутреннее рецензирование. Рассмотренные подробности реализации не только являются критически важными элементами процесса управления изменениями изобразительных материалов, но и могут оказаться полезными при построении решений других типов, ориентированных на «дела».

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=777399
ArticleTitle=Применение платформы IBM FileNet P8 для ускорения разработки новой продукции
publish-date=11302011