Хочу представить на суд хабрасообщества концепцию информационной системы.
Как я обещал ранее в своем блоге, в этом посте я опишу концепцию своей информационной системы. Прошу не судить строго, ведь данный манускрипт является обобщением и формализацией моего скромного опыта в области создания ИС. Публикуя этот документ, я очень хочу бы получить конструктивную критику и предложения по улучшению. Также меня интересует коммерческое применение информационной системы реализованной на этой концепции.
Мне очень интересно работать в данном направлении, хочется создать бесплатный и открытый аналог существующим системам и получить ценный опыт разработки. Пожалуйста не пишите комментарии типа «Не стоит создавать еще один велосипед» или «Комания X и комания Y уже сделали это и успешно продают», но мне будет интересно посмотреть аналоги.
На данный момент существует несколько классов информационных систем:
CRM — системы управления взаимодействием с клиентами
ERP — системы для планирования ресурсов предприятия
MES — производственные управляющие системы
WMS — системы управления складами
SCM — системы для управления цепочками поставок
ECM — системы управления информацией предприятия
EMM — системы автоматизации маркетинга
MRP — системы планирования материальных потребностей
SSDT — единые системы решения задач
EAM — системы управления активами предприятия
HRM — системы управления человеческими ресурсами
ServiceDesk — системы управления ИТ службами
CMS — системы управления контентом
Issue-tracking — системы управления задачами
Workflow — системы управления рабочим потоком
BPMS — системы управления бизнес процессами
В процессе изучения данного вопроса, я обнаружил, что каждый класс информационных систем отличается (возможно описание и анализ каждого класса ИС, станет темой моих следующих постов) друг от друга, в целом, только моделями данных и реализацией последовательности действий над этими данными, и пришел к выводу, что золотой серединой, всех информационных систем является гибрид на основе Workflow и Issue-tracking систем.
Попробую описать этот гибрид на примере небольшой информационной системы управления ИТ службой.
Описываемая информационная система должна состоять из модуля управления заявками и модуля управления ИТ активами.
Терминологию ITIL не использую сознательно, чтобы не нагружать читателя.
Модуль управления заявками — это классический пример Issue-tracking системы, где каждая заявка (issue) определяется статусом и сопроводительными данными, такими как приоритет, описание заявки, данные пользователя, классификация заявки. Жизненный цикл заявки, определяемый статусом заявки, обеспечивается workflow системой, которая описывает этапы работы, какие данные редактируются и какие пользователи участвуют на определенном этапе жизненного цикла. Например, на этапе регистрации заявки участвуют операторы и инженеры технической поддержки и им требуется указать приоритет, описание и данные пользователя. А на этапе закрытия заявки участвуют только инженеры и им необходимо классифицировать заявку иописать ее решение.
Модуль управления ИТ активам представляет из себя БД активов (сервера, рабочие станции, сетевое оборудование, оргтехника, расходные материалы), связанных между собой и классифицированных таким образом, чтобы при определенных условиях можно было увидеть инфраструктуру в определенном разрезе. У каждого актива есть, как минимум, два статуса (активно или неактивно), а также группы активов могут быть доступны тем или иным пользователям. Для более удобного управления активами, необходима интеграция модулей, чтобы было возможно инициировать заявку из управления активами и произвести изменение БД активов из управления заявками. Очевидно, что этот модуль также реализуется с помощью Issue-tracking и Workflow системы.
Абстрагировавшись от предметной области можно определить несколько конструктивных элементов, на основе которых, при правильном подходе, масштабирование ИС управления ИТ службой перестанет быть проблемой.
Управление пользователями
Описание
Подсистема авторизации и управления учетными записями пользователей.
Требования
Должна работать, как самостоятельно, так с помощью LDAP, OpenID и других систем.
Персонализация
Описание
Подсистема организующая механизмы социальных сетей и настройки пользовательского интерфейса.
Требования
Подсистема должна использовать справочники и состоять на основе служебной и справочной информации из следующих компонентов:
— Личная страница
— Личные сообщения
— Связи с другими пользователями
— Группы пользователей
— Личные настройки
— Кастомизация пользовательского интерфейса
— Связи с проектами
— Связи с проектной информацией
— Настраиваемые каналы активности в системе
Управление доступом
Описание
Подсистема управления доступом субъектов к объектам на основе ролей, иерархий ролей и наследования привилегий. Ролевое разграничение доступа позволит реализовать гибкие, изменяющиеся динамически в рабочем потоке правила разграничения доступа.
Проекты, подпроекты
Описание
Подсистема управления проектами и подпроектами, как независимыми и логически связанными информационными системами.
Требования
Подсистема должна обладать возможностью создания пользователем своего проекта или подпроекта и регулироваться с помощью управления доступом. Подсистема должна обеспечивать механизмы связывания проектов и обмена между ними какой-либо информацией для того, чтобы предоставлять гибкий способ комбинирования информационных систем.
Навигация
Описание
Подсистема организации меню, постраничного разделения и тому подобных элементов интерфейса, обеспечивающая быстрый и удобный, интуитивный переход в разные состояния информационной системы.
Трекер
Описание
Подсистема трекер необходима для создания модулей информационной системы.
Требования
Подсистема должна использовать динамически подключаемые справочники определенные в рабочем потоке для гибкой настройки обрабатываемых данных. В рамках одного проекта может быть создано несколько трекеров и они могут быть взаимосвязанными, также один трекер может быть использован в нескольких проектах. Данные из трекеров должны быть переносимыми. У каждого трекера должны быть обязательные атрибуты для определения номера и статуса объектов трекера, дата создания объекта, дата изменения статусов и счетчики изменений, история объекта и комментарии к объекту. Подсистема трекер должна обеспечивать автоматическую генерацию форм редактирования и представлений объектов.
Справочники
Описание
Справочники представляют собой данные, которыми оперирует информационная система. Это могут быть как данные базы данных, так и любая другая структура данных, описывающая некоторые объекты системы и их состояние.
Требования
Компонента должна обеспечивать отображение списка, добавление, редактирование и удаление объектов справочника.
Справочники могут состоять из:
— Основных типов данных
— Списков объектов
— Иерархических списков
— Полей автодополнения
— Классификации по ключевым словам
Интегрированные справочники
Описание
Справочники, подключаемые из источников данных, не используемых в информационной системе, таких как файлы, базы данных и различные сервисы.
Требования
Компонента должна быть обеспечена удобными механизмами настройки интеграции.
Генерация форм
Требования
Подсистема трекер должна быть обеспечена механизмами автоматического и ручного создания форм редактирования данных, такими как:
— Создание\редактирование отдельного объекта
— Создание\редактирование группы объектов
— Перенос объекта\группы
— Интеграция с другими моделями данных
Генерация представлений
Требования
Подсистема трекер должна быть обеспечена механизмами автоматического и ручного создания представлений, таких как:
— Список объектов
— Объект
Шаблонизация
Требования
Подсистема трекер должна быть обеспечена механизмами создания шаблонов заполнения форм, для повышения эффективности добавления и обработки информации.
Фильтры
Описание
Подсистема фильтр необходима для поиска и отображения необходимых данных, в зависимости от выбранного условия фильтрации.
Требования
В подсистеме должны присутствовать условия фильтрации на основе служебной и справочной информации. Подсистема должна обеспечивать многоуровневую сортировку данных. Фильтры должны быть:
— Пользовательские
— Общие
— Привилегированные (доступные определенным пользователям или группам пользователей)
Гибкая отчетность
Описание
Подсистема создания общих и пользовательских отчетов в виде таблиц и графиков на основе справочников и служебной информации.
Экспорт информации (файлы, e-mail, ldap, 3dparty, rss, soap)
Активность в системе
Описание
Подсистема наблюдения за активностью в системе.
Требования
Подсистема должна обеспечить возможность просмотра общей активности, активности в проектах, а так же обеспечить гибкую настройку общих и пользовательских каналов просмотра активности.
Рабочий поток
Описание
Подсистема рабочий поток управляет доступом к данным, описывает последовательность действий пользователя, группы пользователей, простых и комплексных систем. А также обеспечивает своевременное оповещение субъектов о событиях, происходящих в системе.
Доступ к данным
Описание
Компонента управления ролевым доступом к обрабатываемым и отображаемым данным на определенных этапах работы.
Последовательность действий
Описание
Компонента управления последовательности действий в обработке информации.
Требования
Последовательность действий может описываться управляющими структурами, такими как:
— Условия
— Циклы
Автоматическое управление транзакциями
Описание
Компонента, описывающая автоматические операции с обрабатываемыми данными.
Маршрутизация
Описание
Компонента, описывающая маршрутизацию объектов субъектам
Контроль эффективности, производительности и качества
Система оповещений
Описание
Подсистема оповещения о событиях, происходящих в информационной системе посредством внутрисистемных сообщений, электронной почты и rss.
Плагинная система
Примеры плагинов:
— Интеграция в офисные приложения
— Система контроля версий
— Групповой календарь
Импорт, Экспорт проектов
Описание
Механизм, позволяющий переносить с одной платформы на другую и повторно использовать настроенные информационные системы.
Интернационализация
Описав эти конструктивы, я пришел к выводу, что на их основе можно построить любую из существующих информационных систем ориентированных на пользователя, без участия программиста (в отдельных случаях проблема решается созданием необходимого плагина). Существующий класс информационных систем BPMS (Bussines Process Management System), направлен на решение этой же цели, но обладает серьезными минусами, на мой взгляд, и при желании может быть интегрирован в мою концепцию, в виде надстройки графического моделирования рабочих потоков и моделей данных. В остальных существующих классах ИС реализованны механизмы динамической модели и рабочего потока, но, на мой взгляд, пока не в полной мере.
Возможно я описал прописные истины, но для меня это стало, своего рода, открытием. Поэтому я хотел бы обсудить с Вами данную концепцию и перейти к этапу проектирования и реализации этой ИС, описав их в следующем посте.
Как я обещал ранее в своем блоге, в этом посте я опишу концепцию своей информационной системы. Прошу не судить строго, ведь данный манускрипт является обобщением и формализацией моего скромного опыта в области создания ИС. Публикуя этот документ, я очень хочу бы получить конструктивную критику и предложения по улучшению. Также меня интересует коммерческое применение информационной системы реализованной на этой концепции.
Мне очень интересно работать в данном направлении, хочется создать бесплатный и открытый аналог существующим системам и получить ценный опыт разработки. Пожалуйста не пишите комментарии типа «Не стоит создавать еще один велосипед» или «Комания X и комания Y уже сделали это и успешно продают», но мне будет интересно посмотреть аналоги.
На данный момент существует несколько классов информационных систем:
CRM — системы управления взаимодействием с клиентами
ERP — системы для планирования ресурсов предприятия
MES — производственные управляющие системы
WMS — системы управления складами
SCM — системы для управления цепочками поставок
ECM — системы управления информацией предприятия
EMM — системы автоматизации маркетинга
MRP — системы планирования материальных потребностей
SSDT — единые системы решения задач
EAM — системы управления активами предприятия
HRM — системы управления человеческими ресурсами
ServiceDesk — системы управления ИТ службами
CMS — системы управления контентом
Issue-tracking — системы управления задачами
Workflow — системы управления рабочим потоком
BPMS — системы управления бизнес процессами
В процессе изучения данного вопроса, я обнаружил, что каждый класс информационных систем отличается (возможно описание и анализ каждого класса ИС, станет темой моих следующих постов) друг от друга, в целом, только моделями данных и реализацией последовательности действий над этими данными, и пришел к выводу, что золотой серединой, всех информационных систем является гибрид на основе Workflow и Issue-tracking систем.
Попробую описать этот гибрид на примере небольшой информационной системы управления ИТ службой.
Описываемая информационная система должна состоять из модуля управления заявками и модуля управления ИТ активами.
Терминологию ITIL не использую сознательно, чтобы не нагружать читателя.
Модуль управления заявками — это классический пример Issue-tracking системы, где каждая заявка (issue) определяется статусом и сопроводительными данными, такими как приоритет, описание заявки, данные пользователя, классификация заявки. Жизненный цикл заявки, определяемый статусом заявки, обеспечивается workflow системой, которая описывает этапы работы, какие данные редактируются и какие пользователи участвуют на определенном этапе жизненного цикла. Например, на этапе регистрации заявки участвуют операторы и инженеры технической поддержки и им требуется указать приоритет, описание и данные пользователя. А на этапе закрытия заявки участвуют только инженеры и им необходимо классифицировать заявку иописать ее решение.
Модуль управления ИТ активам представляет из себя БД активов (сервера, рабочие станции, сетевое оборудование, оргтехника, расходные материалы), связанных между собой и классифицированных таким образом, чтобы при определенных условиях можно было увидеть инфраструктуру в определенном разрезе. У каждого актива есть, как минимум, два статуса (активно или неактивно), а также группы активов могут быть доступны тем или иным пользователям. Для более удобного управления активами, необходима интеграция модулей, чтобы было возможно инициировать заявку из управления активами и произвести изменение БД активов из управления заявками. Очевидно, что этот модуль также реализуется с помощью Issue-tracking и Workflow системы.
Абстрагировавшись от предметной области можно определить несколько конструктивных элементов, на основе которых, при правильном подходе, масштабирование ИС управления ИТ службой перестанет быть проблемой.
Управление пользователями
Описание
Подсистема авторизации и управления учетными записями пользователей.
Требования
Должна работать, как самостоятельно, так с помощью LDAP, OpenID и других систем.
Персонализация
Описание
Подсистема организующая механизмы социальных сетей и настройки пользовательского интерфейса.
Требования
Подсистема должна использовать справочники и состоять на основе служебной и справочной информации из следующих компонентов:
— Личная страница
— Личные сообщения
— Связи с другими пользователями
— Группы пользователей
— Личные настройки
— Кастомизация пользовательского интерфейса
— Связи с проектами
— Связи с проектной информацией
— Настраиваемые каналы активности в системе
Управление доступом
Описание
Подсистема управления доступом субъектов к объектам на основе ролей, иерархий ролей и наследования привилегий. Ролевое разграничение доступа позволит реализовать гибкие, изменяющиеся динамически в рабочем потоке правила разграничения доступа.
Проекты, подпроекты
Описание
Подсистема управления проектами и подпроектами, как независимыми и логически связанными информационными системами.
Требования
Подсистема должна обладать возможностью создания пользователем своего проекта или подпроекта и регулироваться с помощью управления доступом. Подсистема должна обеспечивать механизмы связывания проектов и обмена между ними какой-либо информацией для того, чтобы предоставлять гибкий способ комбинирования информационных систем.
Навигация
Описание
Подсистема организации меню, постраничного разделения и тому подобных элементов интерфейса, обеспечивающая быстрый и удобный, интуитивный переход в разные состояния информационной системы.
Трекер
Описание
Подсистема трекер необходима для создания модулей информационной системы.
Требования
Подсистема должна использовать динамически подключаемые справочники определенные в рабочем потоке для гибкой настройки обрабатываемых данных. В рамках одного проекта может быть создано несколько трекеров и они могут быть взаимосвязанными, также один трекер может быть использован в нескольких проектах. Данные из трекеров должны быть переносимыми. У каждого трекера должны быть обязательные атрибуты для определения номера и статуса объектов трекера, дата создания объекта, дата изменения статусов и счетчики изменений, история объекта и комментарии к объекту. Подсистема трекер должна обеспечивать автоматическую генерацию форм редактирования и представлений объектов.
Справочники
Описание
Справочники представляют собой данные, которыми оперирует информационная система. Это могут быть как данные базы данных, так и любая другая структура данных, описывающая некоторые объекты системы и их состояние.
Требования
Компонента должна обеспечивать отображение списка, добавление, редактирование и удаление объектов справочника.
Справочники могут состоять из:
— Основных типов данных
— Списков объектов
— Иерархических списков
— Полей автодополнения
— Классификации по ключевым словам
Интегрированные справочники
Описание
Справочники, подключаемые из источников данных, не используемых в информационной системе, таких как файлы, базы данных и различные сервисы.
Требования
Компонента должна быть обеспечена удобными механизмами настройки интеграции.
Генерация форм
Требования
Подсистема трекер должна быть обеспечена механизмами автоматического и ручного создания форм редактирования данных, такими как:
— Создание\редактирование отдельного объекта
— Создание\редактирование группы объектов
— Перенос объекта\группы
— Интеграция с другими моделями данных
Генерация представлений
Требования
Подсистема трекер должна быть обеспечена механизмами автоматического и ручного создания представлений, таких как:
— Список объектов
— Объект
Шаблонизация
Требования
Подсистема трекер должна быть обеспечена механизмами создания шаблонов заполнения форм, для повышения эффективности добавления и обработки информации.
Фильтры
Описание
Подсистема фильтр необходима для поиска и отображения необходимых данных, в зависимости от выбранного условия фильтрации.
Требования
В подсистеме должны присутствовать условия фильтрации на основе служебной и справочной информации. Подсистема должна обеспечивать многоуровневую сортировку данных. Фильтры должны быть:
— Пользовательские
— Общие
— Привилегированные (доступные определенным пользователям или группам пользователей)
Гибкая отчетность
Описание
Подсистема создания общих и пользовательских отчетов в виде таблиц и графиков на основе справочников и служебной информации.
Экспорт информации (файлы, e-mail, ldap, 3dparty, rss, soap)
Активность в системе
Описание
Подсистема наблюдения за активностью в системе.
Требования
Подсистема должна обеспечить возможность просмотра общей активности, активности в проектах, а так же обеспечить гибкую настройку общих и пользовательских каналов просмотра активности.
Рабочий поток
Описание
Подсистема рабочий поток управляет доступом к данным, описывает последовательность действий пользователя, группы пользователей, простых и комплексных систем. А также обеспечивает своевременное оповещение субъектов о событиях, происходящих в системе.
Доступ к данным
Описание
Компонента управления ролевым доступом к обрабатываемым и отображаемым данным на определенных этапах работы.
Последовательность действий
Описание
Компонента управления последовательности действий в обработке информации.
Требования
Последовательность действий может описываться управляющими структурами, такими как:
— Условия
— Циклы
Автоматическое управление транзакциями
Описание
Компонента, описывающая автоматические операции с обрабатываемыми данными.
Маршрутизация
Описание
Компонента, описывающая маршрутизацию объектов субъектам
Контроль эффективности, производительности и качества
Система оповещений
Описание
Подсистема оповещения о событиях, происходящих в информационной системе посредством внутрисистемных сообщений, электронной почты и rss.
Плагинная система
Примеры плагинов:
— Интеграция в офисные приложения
— Система контроля версий
— Групповой календарь
Импорт, Экспорт проектов
Описание
Механизм, позволяющий переносить с одной платформы на другую и повторно использовать настроенные информационные системы.
Интернационализация
Описав эти конструктивы, я пришел к выводу, что на их основе можно построить любую из существующих информационных систем ориентированных на пользователя, без участия программиста (в отдельных случаях проблема решается созданием необходимого плагина). Существующий класс информационных систем BPMS (Bussines Process Management System), направлен на решение этой же цели, но обладает серьезными минусами, на мой взгляд, и при желании может быть интегрирован в мою концепцию, в виде надстройки графического моделирования рабочих потоков и моделей данных. В остальных существующих классах ИС реализованны механизмы динамической модели и рабочего потока, но, на мой взгляд, пока не в полной мере.
Возможно я описал прописные истины, но для меня это стало, своего рода, открытием. Поэтому я хотел бы обсудить с Вами данную концепцию и перейти к этапу проектирования и реализации этой ИС, описав их в следующем посте.
