Место SaaS в бизнес-модели предприятия

SaaS предполагает использование программного и аппаратного обеспечения, установленного на стороне. При этом предприятие экономит свои ресурсы: нет необходимости в собственных программистах и администраторах, которые разрабатывают информационную систему и обслуживают ее. Т.е. все технические работы выполняет поставщик SaaS, провайдер. А непосредственные работники предприятия лишь используют программу в качестве бизнес-инструмента. В связи с территориальной распределенностью пользователя и провайдера SaaS-продукта, программное обеспечение в этой методологии основано на облачных веб-технологиях в режиме клиент-сервер: доступ пользователя (клиента) реализуется к провайдеру (серверу) с помощью интернет-браузера. Наиболее распространенным примером, иллюстрирующим суть методологии SaaS, являются многочисленные почтовые сервисы: Gmail, Яндекс, Yahoo! и др. Здесь же следует отметить различные файлообменные сервисы и кибердисковые пространства, а также online-сервесы, которые позволяют нарезать музыку.

Однако, почта и файловые хранилища используются не только предприятиями, а являются повседневной услугой в секторе B2C. С точки зрения корпоративного клиента сегодня большое распространение получают online КИС (корпоративные информационные системы) категорий СЭД (NauDoc, qFlow, DocsVision Live), CRM (Мегаплан, Консильери, amoCRM, Битрикс24, Fat Free CRM), ERP (NetSuite, Compiere, Open ERP, а также специальные SaaS-версии MS Navision, 1C, SAP и других флагманов линейки КИС), PM (Мегаплан, LiquidPlanner, TeamWork, Zoho Projects) и т.д. Также нельзя не отметить решения для совместной разработки программного обеспечения (Сompilr) и работы с документами (Google Docs).

Но сегодня ИТ-аутсорсинг в секторе B2B не ограничивается лишь арендой выбранного SaaS-обеспечения. Помимо типового набора КИС (СЭД, CRM, ERP) следует упомянуть другие услуги, отдаваемые на аутсорсинг, например, продвижение бренда и привлечение новых клиентов с помощью специальных сайтов рекламных скидок (biglion, kupongid и т.д.), sms- и email-рассылок. Таким образом, ведение бизнеса становится похоже на игру в конструктор, когда из множества разных частей нужно собрать единое целое. А братья-погодки, методологии IT-Аутсорсинга и SaaS — отличные помощники в этом интересном деле.

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

Можно выделить несколько программных технологий организации ЕИП предприятия:

• в рамках одной программной платформы (например, продукты Microsoft интегрированы между собой через средства OLE/ActiveX/API);
• синхронизация баз данных различных ИС;
• централизация информации с помощью одной системы, в которой представлен полный набор всех данных;
• организация доступа к информации, которая распределено хранится в базах данных разных ИС с помощью их интеграции между собой (технологии COM, CORBA, SOA, ESB и т.д.).

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

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

Однако, насколько рентабельны временные, трудовые и финансовые затраты на все эти действия? Действительно ли возможна совместная многопользовательская работа в среде ЕИП? Достигаются ли в реальности все прогнозируемые эффекты оптимизации деятельности?

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

Но, в целом, нельзя сказать, что создание ЕИП предприятия невозможно. Интеграция информационных ресурсов и систем компании во многом облегчит ее проектную, финансовую, управленческую деятельность. Однако, для организации ЕИП предприятия необходимы следующие условия:

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

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

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

Информационные системы управления данными

Автоматизировать управление ЖЦ документа позволяют информационные системы (ИС) управления данными, среди которых выделяют категории систем PDM (от англ. Product Data Management – управление данными о продукции) и ECM (от англ. Electronic Content Management – управление электронными данными).

Как правило, современные ИС указанных категорий являются многопользовательскими и поддерживают одновременную работу нескольких человек с одним документом, сохраняя при этом единство и целостность данных. Это обеспечивается инструментами гибкой настройки прав пользователей согласно их потребностям. Также полезной функцией PDM- и ECM-систем является возможность существования нескольких версий документа. Кроме того, PDM-системы, наряду с функциями ECM по управлению офисной документацией, обеспечивают просмотр и оперативную правку файлов различных инженерных форматов (CAD/CAE/CAM), а также выполнение других специфических операций, например, формирование спецификаций и т. д. Для этого многие PDM-системы поддерживают интеграцию с широко используемыми CAD/CAE/CAM-пакетами, например Windchill и Pro/ENGINEER; Enovia SmarTeam и CATIA, AutoCAD, SolidWorks, DELMIA; Teamcenter и NX, Solid Edge, Tecnomatix и т. д.

Однако, управление документами в данных ИС реализуется по-разному. Рассмотрим это более подробно на примере PDM-системы Enovia SmarTeam производства IBM и Dassault Systems и отечественной ECM-системы DIRECTUM, разработанной одноименной российской компанией. Эти программные продукты широко распространены на многих российских предприятиях и используются авторами данной статьи в Томском политехническом университете на протяжении нескольких лет в рамках подготовки специалистов по направлению «Информационные системы и технологии в бизнесе».

Понятие «Документ» в системах управления данными

Термин «документ» в ИС управления данными соответствует определению стандарта Р 50.1.031, согласно которому электронный документ – это информационный объект, состоящий из двух частей:

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

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

В ECM-системах, ориентированных на автоматизацию операций делопроизводства, документ является первичной и конечной сущностью. В PDM-системах, предназначенных, в первую очередь, для управления инженерными данными конструкторско-промышленных предприятий, первичной считается материальная сущность – проектируемый объект: деталь, блок, часть изделия и т. д. Данная сущность называется «элемент». Количество и варианты соединения элементов между собой определяются структурой изделия. Документ является вторичной информационной сущностью, которая сопровождает элемент на различных этапах его ЖЦ: эскизная разработка, конструкторское проектирование и т. д. При этом у одного и того же элемента на разных этапах его ЖЦ может отличаться содержимое документов одинакового назначения. Например, спецификация на блок при эскизном проектировании может отличаться от спецификации на этот же самый блок на этапе его запуска в производство. Таким образом, именно уникальные особенности предметной области – процессы создания комплексных инженерных изделий – определяют концептуальную основу PDM-систем: смысл терминов «элемент» и «документ» и отношения между ними.

Жизненный цикл документа в информационных системах управления данными

Отмеченная разница концепции термина «документ» в PDM- и ECM-системах отражается в этапах ЖЦ данного объекта и последовательности перехода между ними. ЖЦ практически каждого документа начинается с этапа разработки, затем документ становится действующим и доступным для использования до истечения его срока действия. Стандарты ЕСКД [1–3] предусматривают несколько возможных состояний ЖЦ документа, в т. ч. характеристики его аутентичности: оригинал, подлинник и копия. Этот аспект должен быть отражен при работе с документами в ИС управления данными.

В силу своей предметной направленности — управление офисным документооборотом, ECM-система DIRECTUM позволяет настраивать этапы ЖЦ и вводить собственные для различных видов документов посредством добавления новых записей в справочники «Виды электронных документов» и «Виды жизненных циклов». При этом проектирование ЖЦ документа осуществляется в графическом режиме с помощью встроенного редактора DIRECTUM на основе функционала MS Visio. На рис. 1 показан пример проектирования ЖЦ для документа вида «Входящий счет на оплату».

Рис.1 Проектирование ЖЦ документа с помощью встроенного редактора DIRECTUM

Подобная возможность отсутствует в PDM Enovia SmarTeam – документы могут находиться только в одном из типовых этапов ЖЦ, предопределенных спецификой данной ИС:

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

На рис. 2 показаны типовые этапы ЖЦ документа в PDM-системе Enovia SmarTeam и операции по их изменению.

Рис.2 Жизненный цикл документа в PDM-системе Enovia SmarTeam

Продолжая сравнение ЖЦ документа в PDM Enovia SmarTeam и ECM DIRECTUM, следует отметить, что при создании документа в DIRECTUM на сервере БД генерируется новая запись в СУБД, в которую вносятся метаданные объекта. Тело документа (файл), в зависимости от его размера и настроек ИС, размещается в файловом хранилище или в СУБД и с этого момента становится доступным всем пользователям ИС, которые обладают правами хотя бы на просмотр данного объекта.

В PDM-системе Enovia SmarTeam объект типа «документ» может находиться только в одном из вышеописанных типовых предопределенных этапов ЖЦ, и даже широкий набор инструментов администрирования данной ИС не позволяет задать свои правила ЖЦ для документа. При этом для объекта типа «элемент» существует возможность ввода новых состояний его ЖЦ согласно правилам предприятия и/или последовательности технологических этапов.

Отсутствие инструментов конфигурирования ЖЦ документа в Enovia SmarTeam приводит к необходимости поиска решений, которые могут быть реализованы средствами этой ИС. Таким образом, перед авторами статьи была поставлена задача управления ЖЦ документа в Enovia SmarTeam в соответствии со стандартами ЕСКД [1–3]. Актуальность данной задачи обусловлена внедрением указанной ИС в процессы разработки сложной высокотехнологической продукции на отечественных предприятиях машиностроительной отрасли промышленности.

Предлагаемый авторами статьи способ управления ЖЦ документа согласно стандартам ЕСКД в Enovia SmarTeam основан на атрибутах класса объектной модели данных рассматриваемой ИС.

Модель данных систем управления информацией

Согласно [4], объектная модель данных (МД) хранится в базе данных (БД) и представляет собой абстрактную логическую структуру взаимосвязанных объектов с одинаковым поведением и свойствами. Такая концепция соответствует направлению объектно-ориентированных баз данных, которое объединяет парадигмы объектно-ориентированного программирования и реляционной структуры БД [5]. Таким образом, экземпляры классов объектной МД на физическом уровне представляют собой записи таблиц в реляционной БД.

Объектно-реляционная структура данных реализована в ECM-системе DIRECTUM с помощью справочников – таблиц БД, в которых хранятся объекты с одинаковым поведением, например, «электронные документы», «задачи», «пользователи» и т. д. Подобная типизация объектов в PDM-системе Enovia SmarTeam определяется понятием «класс», экземпляры которого характеризуются одними и теми же атрибутами. Продолжая анализ объектной модели данных PDM Enovia SmarTeam, следует отметить ее структурированность: класс самого верхнего уровня иерархии называется суперклассом и является абстрактным. Инструменты администрирования Enovia SmarTeam позволяют проектировать модель данных для реализации специфических задач, например, добавлять свои классы, атрибуты и т. д. Типовые этапы ЖЦ документа в Enovia SmarTeam являются значениями атрибута «State» у суперкласса «Документы» и не подлежат изменению. Таким образом, изменить предопределенные типовые этапы ЖЦ документа в стандартном функционале Enovia SmarTeam не представляется возможным. Поэтому необходимо ввести новый атрибут, который будет отображать состояние ЖЦ документа согласно ЕСКД [1].

Управление ЖЦ документа в Enovia SmarTeam

Возвращаясь к поставленной задаче – реализация различных состояний ЖЦ документа в соответствии со стандартами ЕСКД [1–3] в Enovia SmarTeam – следует определить классу «Документ» атрибут, который будет выражать необходимое состояние ЖЦ. Поскольку набор возможных значений состояний ЖЦ документа ограничен ЕСКД, спецификой отрасли и предприятия, разрабатываемый атрибут будет представлять собой выбор из заранее созданного перечня возможных значений. Например, согласно [1], электронный документ после подписания и утверждения в установленном порядке может находиться в одном из следующих состояний: оригинал, подлинник, копия. На рис. 3 показана работа с данным атрибутом в Enovia SmarTeam.

Рис.3 Фрагмент карточки объекта класса «Документ» в интерфейсе пользователя PDM-системы Enovia SmarTeam

Важно отметить, что значения разработанного атрибута «Состояние ЖЦ» зависит от значений атрибута «State», который реализует встроенный механизм управления ЖЦ объекта в терминах системы. Например, значения «Подписанный», «Утвержденный», «Оригинал», «Подлинник» или «Копия» у атрибута «Состояние ЖЦ» возможны только если атрибут «State» обрабатываемого объекта находится в значении «Согласованный». Автоматизированное изменение значения разработанного атрибута «Состояние ЖЦ» документа в Enovia SmarTeam реализуется с помощью скриптов – программ на внутреннем языке данной ИС. Подобная программная настройка Enovia SmarTeam представляет собой целую область различных задач и требует подробного рассмотрения в отдельной статье.