Концепция ЕИП (Единого Информационного Пространства)

Единое Информационное Пространство (ЕИП)
Концепция построения. Описываем основные требования к хранению информации так, чтобы ею можно было пользоваться одновременно из разных процессов.
Единое Информаионное Пространство (ЕИП) представляет собой совокупность взаимосвязанной информации, определяющей состояние и деятельность организации.
ЕИП предназначено для гарантии хранения и унификации доступа ко всей информации, хранящейся в организации (компании, подразделении, группе).
Целью создания ЕИП является гарантия актуальности и доступности всей информации в организации.
Задачи ЕИП:
• Обеспечение доступа ко всей информации, находящейся в организации;
• Автоматизация деятельности по поддержанию информации в актуальном состоянии.
Основным принципом ЕИП является принцип «голландских часов», то есть гарантии, что информация в ЕИП эталонная, корректная и является первоисточником для принятия всех решений в организации.
Концепция автоматизации
Автоматизация управленческих процессов сводится, в большинстве случаев, к отслеживанию жизненного цикла определенных объектов с учетом сложных условий взаимодействия и взаимного влияния.
Система автоматизации должна поддерживать хранение:
• Объектов;
• Связей между объектами;
• Правил работы с объектами.
Объекты могут быть двух типов:
• Объекты, составляющие компоненты ИТ-инфраструктуры и бизнес-приложений (сервера, экземпляры приложений и БД, остальные элементы, попадающие под понятие «конфигурационных единиц»);
• Объекты управления (Инциденты, Заявки, Инструкции, Проблемы и т.п. элементы, которые не несут в себе информацию о каком-либо объекте или сущности, но являются хранением информации о действиях).
Между объектами должны поддерживаться связи следующих типов:
«1-1». В этом случае один объект может быть однозначно связан с другим объектом. Пример – Инцидент имеет атрибут «Координатор», в котором можно указать только одного сотрудника.
«1 — ∞». В этом случае с одним объектом могут быть связаны несколько объектов другого типа. Пример: Проблема имеет несколько связанных с ней Инцидентов, которые отображаются списком в карточке Проблемы.
«∞ — ∞». Данная ситуация должна быть реализована с помощью кросс-таблицы, имеющей данные по связям объектов разного типа. Пример: Сотрудник может состоять в нескольких ролях, и при этом каждая их ролей может включать несколько сотрудников.
Каждый объект должен иметь следующие обязательные атрибуты и данные:
• Уникальный Код;
• Название;
• Статус (из справочника статусов для данного объекта);
• Описание;
• Дата/время создания;
• Сотрудник, создавший объект;
• Дата/время изменения;
• Сотрудник, который произвел последнее изменение;
• Блок прикрепленных файлов;
• История изменений.
Справочник статусов для каждого объекта должен включать в себя следующую информацию:
• Код статуса;
• Название статуса;
• Варианты перехода в другие статусы из текущего состояния;
• Роли, имеющие право на перевод статуса;
• Скрипты, определяющие проверки при смене статуса.
Для полноценной автоматизации любых действий с объектами, необходимо наличие следующих вариантов выполнения скриптов (триггеров):
• Создание экземпляра объекта («до» и «после»);
• Удаление экземпляра объекта («до» и «после»);
• Изменение значения атрибута («до» и «после»);
• Прикрепление файла к объекту («до» и «после»);
• Добавление комментария («до» и «после»).
Скрипты должны иметь следующие возможности:
• Проверка прав доступа текущего пользователя.
• Рассылка оповещений через все возможные каналы связи (как минимум email и sms).
• Доступ ко всем объектам ЕИП и их атрибутам по связке «тип объекта + код объекта» на чтение и запись. При этом код и тип инцидента должны иметь возможность быть динамически сформированы Например:
INCIDENT.INC-001.DESCRIPTION = «текст»
PROBLEM.{this.Код_Проблемы}.STATUS = CLOSED
• В скриптах должна быть возможность программирования базовой логики, доступной в основных языках программирования:
• Циклы while-do и do-until;
• Циклы for и for-each;
• Конструкция if-then-else.
• Возможность прерывания действия (как «до», так и «после») в случае невыполнения определенных условий.
Система автоматизации должна иметь общую аутентификацию всех пользователей, основанную на ролевой модели.
Права доступа должны иметь возможность выдаваться на объект и на атрибут. В случае, если на объект доступ на чтение есть, а на атрибут – нет, карточка объекта должна показываться без этого атрибута.
Каждый объект может иметь несколько шаблонов отображения. Каждый шаблон привязан к Роли. Если шаблонов больше одного, то у одного из шаблонов должен быть признак «шаблон по умолчанию».
Уникальность кодов объектов должна быть в пределах всего ЕИП.

Добавить комментарий

Ваш адрес email не будет опубликован.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.