46
6. Проведение ОПЭ и переход в ПЭ.
Основные этапы и ожидаемые результаты приведены в таблице 1.8.
Таблица 1.8
Основные этапы и ожидаемые результаты реализации по
каждому из этапов
№
Фаза
Срок
реализации
Ожидаемый результат по этапу
1
Анализ и подготовка проекта
1 месяц
Отчет о функциональном анализе AsIs
2
Концептуальное
проектирование
2 месяца
Проектные решения по всем бизнес-
процессам; проектное решение по
ведению НСИ; концепция ролей и
полномочий
3
Разработка АС МиАЭ
2 месяца
Создание хранилища данных;
реализация форм ввода и отчетности;
реализация хранилища документов с
интерфейсом
загрузки/выгрузки/просмотра
4
Приемочные испытания.
Подготовка ОПЭ
0,5 месяца
Проект переведен в ОПЭ
5
Проведение ОПЭ и переход в
ПЭ
1,5 месяца
Проект переведен в ПЭ
В рамках данного проекта применяется автоматизация по
направлениям, что подразумевает автоматизацию отдельных направлений
деятельности предприятия, таких, как производство, сбыт, управление
финансами, в данном случае речь идет о процессе автоматизации
энегоэффективности.
В данном случае подход, связанный с автоматизацией по
направлениям, применяется, когда конечной целью работ является полная
автоматизация предприятия. Реализация данного вида автоматизации
связана с регламентацией бизнес-процессов и требует создания модели
всего предприятия.
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
Все входные и выходные документы в рамках АС МиАЭ
унифицированы в соответствии с формами, утверждёнными Приказами
компании № 399 от 11.07.2012, № 340 от 23.07.2012 и приведенными в п.
47
1.2.2, так как именно они утверждают мероприятия по мониторингу и
анализу энергоэффективности в рамках компании.
Функциональный блок ввода данных выполняет следующие
функции: ввод данных, корректировка данных, утверждение введенных
данных.
Функциональный блок ввода данных реализуется на основе SAP BI
Integrated Planning путем использования BEx-запросов, доступных для
ввода. Инструментом ввода данных Integrated Planning является BEx-
запрос, доступный для ввода, который позволяет осуществлять ввод
значений показателей по заранее заданным перечню признаков. Задание
перечня признаков осуществляется путем создания уровней агрегации на
основе инфо-куба реального времени. Для организации ввода данных во
временных разрезах (месяц, квартал, год) в решении задействованы
уровни агрегации.
Функциональный блок визуализации и пользовательской
отчетности предназначен для формирования и отображения в привычной
для пользователя среде MS Excel отчетных форм заданного шаблона,
графиков и диаграмм. Данный блок реализован на основе приложения BEx
Analyzer и BEx-запросов.
В отчетах возможны подкрашивания ячеек с показателями любым
цветом, в зависимости от величины отклонения показателя от нормы. Все
отчеты можно сохранить локально на компьютере в следующих форматах:
xls, pdf, xml, doc, csv и прочих.
Пользователь имеет возможность создать произвольные формы
аналитической отчетности. При этом система также обеспечивает
возможность сохранения пользовательских форм отчетов локально.
Состав классификаторов в рамках АС МиАЭ определен для
обеспечения единого представления полного объема статической
информации, согласно которой осуществляется мониторинг выполнения
мероприятий по энергосбережению.
48
Состав классификаторов предопределяет возможность ведения
типовых реестров и справочников. К типовым справочникам и реестрам
относятся:
- типовые атрибуты объектов потребления;
- типы приборов учета;
- энергоресурсы и характеристики среды;
- единицы измерения;
- мероприятия по энергосбережению;
- виды мероприятий по энергосбережению;
- типовые учетные показатели потребления;
- типовые целевые показатели энергоэффективности;
- типовые индикаторы энергоэффективности;
- типы объектов потребления;
Среди перечисленных реестров и справочников должны быть
отдельно выделены:
-перечень атрибутов объектов потребления;
- типовые учетные показатели потребления;
- индикаторы энергоэффективности.
Перечисленные реестры имеют иерархическую структуру,
повторяющую структурную иерархию соответствующего уровня: для
каждой записи реестра должно быть указано, к какому уровню иерархии
она относится. Для каждого индикатора имеется алгоритм его расчета на
основании индикаторов более низких уровней иерархии (при наличии
таковых) и/или индикаторов того же уровня.
Таким образом, для обозначенных целей в системе реализованы
справочники, представленные в таблице 1.9.
49
Таблица 1.9
Реестр справочников
Наименование
справочника
Ответственный
Средний
объем, кол-во
записей
Частота
актуализации
Объем
актуализации,
%
Виды
транспортных
средств
Служба НСИ
6
Ежеквартально
0%
Топливно-
энергетические
ресурсы
Служба НСИ
5
Ежеквартально
0%
Мероприятия
Служба НСИ
15
Ежеквартально
0%
Тип
мероприятия
Служба НСИ
3
Ежеквартально
0%
Тип данных
Служба НСИ
3
Ежеквартально
0%
Транспортные
средства
Служба НСИ
1200
Ежеквартально
5-10%
Способ организации информационной базы в рамках системы – это
интегрированная база данных с распределённой организацией, что связано
с территориальной распределённостью филиалов компании.
Используется информационная база данных с трехзвенной
архитектурой - Сервер базы данных - Сервер приложений -Клиент.
В результате работа построена следующим образом:
- База данных в виде набора файлов находится на жестком диске
специально выделенного компьютера (сервера сети).
- СУБД располагается также на сервере сети.
- Существует специально выделенный сервер приложений, на
котором располагается программное обеспечение (ПО) делового анализа
(бизнес-логика).
- Существует множество клиентских компьютеров, на каждом из
которых установлен так называемый "тонкий клиент" – клиентское
приложение, реализующее интерфейс пользователя.
- На каждом из клиентских компьютеров пользователи имеют
возможность запустить приложение – тонкий клиент. Используя
предоставляемый приложением пользовательский интерфейс, он
50
инициирует обращение к ПО делового анализа, расположенному на
сервере приложений.
- СУБД инкапсулирует внутри себя все сведения о физической
структуре БД, расположенной на сервере.
- СУБД инициирует обращения к данным, находящимся на сервере,
в результате которых результат выполнения запроса копируется на сервер
приложений.
- Сервер приложений возвращает результат в клиентское
приложение (пользователю).
- Приложение, используя пользовательский интерфейс, отображает
результат выполнения запросов.
Для организации хранения файлов используется стандартное
хранилище ПО SAP BI, в котором организовано хранение файлов во
внутреннем формате.
1.4.2. Обоснование проектных решений по программному
обеспечения
Требования к программному обеспечению для решения всех
озвученных задач включают в себя:
- требования к функциональности;
- требования к способам и средствам связи между компонентами;
- требования к надежности;
- требования к эргономике и технической эстетике;
- требования к защите информации от несанкционированного
доступа;
- требования к защите от разрушений при авариях.
Требования к функциональности системы
Логическая архитектура функциональности система должна
состоять из следующих подсистем [16]:
- подсистема ведения нормативно-справочной информации:
справочников;
51
- подсистема межмодульного взаимодействия и интеграции;
- подсистема информационной безопасности;
- подсистема регистрации и мониторинга событий;
- подсистема ввода, расчета и анализа данных;
- подсистема пользовательской отчетности.
Требования к перечню функций, которые должны выполнять
подсистемы, представлены в таблице 1.10.
Таблица 1.10
Перечень функций, которые должны выполнять
подсистемы
Наименование
подсистемы
Описание функциональных возможностей
Подсистема
ведения
справочников
ведение типовых реестров и справочников;
ведение реестра показателей и индикаторов энергоэффективности;
создание, редактирование и удаление записей реестра/справочника.
Подсистема
межмодульного
взаимодействия и
интеграции
ручной ввод данных о потреблении ТЭР для пользователей уровня
организаций и их филиалов;
автоматизированный сбор данных о потреблении энергоресурсов с
приборов учета ТЭР;
импорт данных из систем коммерческого и технического учета ТЭР;
ручной ввод данных о потреблении ТЭР;
интеграция с внешними системами;
Подсистема
информационной
безопасности
управление пользователями;
управление ролями пользователей;
разграничение доступа пользователей к информации в системе и
защита информации от несанкционированного доступа
Подсистема
регистрации и
мониторинга
событий
управление событиями;
обмен сообщениями
Подсистема ввода,
расчета и анализа
данных
ведение программы энергосбережения и повышения
энергоэффективности (редактирование списка мероприятий,
указывание источников финансирования для каждого мероприятия,
объемов финансирования и т.д.);
формирование реестра программ по энергосбережению и повышению
энергоэффективности;
сбор значений показателей и индикаторов энергоэффективности
текущей организации и подчиненных организаций;
формирования пользователем планов и перечней мероприятий по
энергосбережению на основе реестра типовых мероприятий;
ввод пользователем расчетных коэффициентов в ручном режиме через
специализированные формы настройки входных параметров
алгоритмов расчета целевых показателей и индикаторов;
добавление новых или изменение существующих расчетных
алгоритмов расчета целевых показателей;
мониторинг значений индикаторов и показателей выполнения
Программы.
Подсистема
ведение базы регламентированной и типовой отчетности;
52
Наименование
подсистемы
Описание функциональных возможностей
пользовательской
отчетности
автоматизированное формирование типовых отчетов;
генерация нетиповых отчетов с использованием конструктора
отчетных форм;
предоставление консолидированной информации
(специализированные витрины данных);
Требования к способам и средствам связи между компонентами.
Информационный обмен между компонентами КИСУ должен
осуществляться с использованием существующей телекоммуникационной
инфраструктуры компании.
На транспортном и сетевом уровнях взаимодействия модели
должен использоваться стек протоколов TCP/IP. На уровне приложений
должны использоваться защищенные средства передачи данных для связи
с внешними системами, содержащими персональные данные.
Требования к надежности.
Разрабатываемая функциональность должна обеспечивать защиту
данных от разрушений при авариях и сбоях.
В системе необходимо использовать средства резервного
копирования данных. Запуск резервного копирования не должно требовать
остановки системы.
Компоненты КИСУ должны использовать бесперебойные
источники электропитания.
Требования к эргономике и технической эстетике.
Система должна допускать возможность ввода данных и команд
множеством разных способов (клавиатура, мышь) и много вариантность
доступа к функциям (например, с помощью икон, «горячих клавиш»,
меню). Кроме того, в системе должна быть учтена возможность перехода и
возврат от окна к окну, от режима к режиму, и правильно обрабатывать
такие ситуации.
Графический интерфейс пользователя должен быть построен на
основе следующих принципов (в рамках отдельных подсистем):
53
- Единство базовых текстовых, цветовых и графических
обозначений.
- Однотипный интерфейс навигации по экранным формам.
- Обеспечение многооконного режима.
- Простота.
Требования к защите информации от несанкционированного
доступа.
Система должна обеспечивать возможность ролевого
разграничения прав доступа пользователей и администраторов к своим
информационным ресурсам в соответствии с разработанной матрицей
доступа. Матрицей доступа является отношение множества бизнес-ролей
пользователей Системы к набору ее бизнес-функций (операций, отчетов,
данным и др.).
Система должна обеспечивать возможность ведения и
централизованного администрирования единого списка пользователей,
отражающего права доступа пользователей к Системе.
Должна обеспечиваться возможность мониторинга и
протоколирования действий пользователей при работе с функциями
Системы.
Необходимо предусмотреть автоматическую блокировку сессий
пользователей и приложений по заранее заданным временам отсутствия
активности со стороны пользователей и приложений.
Защита от разрушений при авариях
Должна быть обеспечена гарантированная сохранность всех
данных, хранимых на серверах и системах хранения.
Должна присутствовать документация, описывающая средства и
методику эксплуатации программного обеспечения, обеспечивающие
сохранность информации в базе данных при авариях и отдельных сбоях. А
также восстановление (в случае необходимости) данных по состоянию на
конец рабочего дня, предшествующего аварии. Данная методика должна
54
базироваться на использовании системных средств защиты от аварий и
отдельных сбоев. Резервные копии данных должны храниться минимум
месяц с момента создания.
На основании вышеизложенного может быть выбрано широкое
количество возможных программных продуктов, соответствующих
вышеуказанным требованиям.
Ключевым определяющим критерием является требование о том,
что АС МиАЭ является подсистемой в рамках системы КИСУ Компании,
которая реализована на платформе SAP. Кроме того, необходимость
возможности интеграции с другими автоматизированными системами в
случае выбора другого программного обеспечения повлекла бы
дополнительные затраты на интеграцию с другими системами.
Таким образом, для реализации системы был выбран программный
продукт SAP и иные альтернативы в рамках проекта не рассматривались.
1.4.3.Обоснование проектных решений по техническому
обеспечению
Техническая инфраструктура – это совокупность технических и
системных программных средств, линий связи, процедур, нормативных
документов и т.п., обеспечивающая основу для функционирования всех
информационных сервисов компании [24, стр. 35].
В компании действуют унифицированные требования,
предъявляемые к техническому обеспечению информационных систем. В
п.1.1.3 настоящей работы приведены общие характеристики по
техническому обеспечению, действующие в компании для всех
информационной систем. Также есть отдельные характеристики
технической инфраструктуры, которые определяются в отдельности для
каждой подсистемы КИСУ.
В данном разделе будут рассмотрены именно специфические
характеристики технической инфраструктуры, определяемые для каждой
подсистемы, а также приведены расчеты их обосновывающие. В
55
остальном применяются уже указанные общие требования по
техническому обеспечению.
К специфическим характеристикам технической инфраструктуры,
определяемым для каждой подсистемы, относят:
- требования к системе разработки SAP BI;
- требования к системе проверки качества SAP BI;
- требования к системе продуктивной эксплуатации SAP BI;
- требования к системе разработки хранилища данных;
- требования к продуктивной системе;
- требования к локальной сети;
- требования к пропускной способности каналов связи между
серверами системного ландшафта.
Итоговые требования к системе разработки SAP BI; к системе
проверки качества SAP BI; к системе продуктивной эксплуатации SAP BI;
к системе разработки хранилища данных; к продуктивной системе
приведены в таблице 1.11.2.
Таблица 1.11
Требования к системе разработки SAP BI для новой
функциональности КИСУ – АС МиАЭ
Требование
Важность
(1-3)
1. Система разработки SAP BI
1.1. Требования к подсистеме АС МиАЭ
Число процессоров – не менее 1.
3
Объем оперативной памяти – не менее 2 Гбайт.
3
Дисковая память для хранения данных – не менее 293 Гбайт
Желательно использование внешнего дискового массива.
3
1.2. Требования для всех подсистем КИСУ, в т.ч. и для подсистемы АС МиАЭ
Сетевой адаптер с пропускной способностью не менее 100 Мбит/сек
3
Периферийное оборудование – DVD-ROM.
3
ИБП, обеспечивающий время работы 15 минут.
3
2. Система проверки качества SAP BI
2.1. Требования к подсистеме АС МиАЭ
Число процессоров – не менее 2.
3
Объем оперативной памяти – не менее 4 Гбайт.
3
Дисковая память для хранения данных – не менее 293 Гбайт
Желательно использование внешнего дискового массива.
3
2.2. Требования для всех подсистем КИСУ, в т.ч. и для подсистемы АС МиАЭ
Сетевой адаптер с пропускной способностью не менее 100 Мбит/сек
3
Периферийное оборудование – DVD-ROM.
3
ИБП, обеспечивающий время работы 15 минут.
3