42
Плюсы: снижение риска при введении системы за счет этапов
реализации проекта; уменьшение затратности в ходе проекта,
осуществление шаблонных решений.
Минусы: увеличиваются сроки реализации проекта, увеличение
риска при тиражировании, если появляется большое количество
процессов, которые не входят в шаблоны; повышение стоимости
комплекса проектов за счет дополнительного внедрения проектов
тиражирования.
Исторически имеются шаблонные разрешения (или определяется
какое либо из предшествующих ранее решений шаблонным),
тиражирующиеся в случае вливания других организаций.
Плюсы: при подобном решение не учитываются потребность
некоторых ДО, и это может привести к возникновению определенных
рисков по определению нового процесса в локальной части; уменьшение
затратности в ходе реализации проекта.
Минусы: уменьшение сроков внедрения проекта; определенные
риски при реализации, при возникновении некоторого количества
процессов, которые не входят в шаблоны.
Указанные подходы в процессе осуществления внедрения системы
имеют свои минусы и плюсы, определяющие подбор решений которые
зависят от настоящей ситуации при организации и определении цели
проектов.
В базе успешного введения шаблонных разрешений включена
детально проработанные методологические шаблонные части. Задачами
методологических проработок шаблонных частей осуществляется в ходе
всей реализации системы. На этапах проектировки, чаще всего, имеются
некоторое количество организаций, которые имеют разную особенность, и
используют определенные системы автоматизации [21, с. 69].
43
На данном этапе важно заложить основы будущего шаблонного
решения путем детального анализа процессов, желательно на всех
предприятиях, входящих в объем проекта. При таком подходе только
активное участие владельцев БП КУ позволяет получить на выходе
жизнеспособное проектное решение шаблонной части. Шаблонную часть
возможно выделять в виде бизнес-процессов либо конкретных функций
(транзакций). Уровень детализации шаблонных процессов определяется
исходя из потребностей конкретного проекта.
На этапе сопровождения в целях удержания шаблонной части
необходимо разработать стратегию управления изменениями,
включающую в себя детально прописанные алгоритмы внесения
изменения шаблонной части, уровни согласующих данные изменения,
порядок тестирования и переноса данных изменений. Данные функции
должны быть централизованы в рамках общества. Техническая реализация
Рассмотрим техническую реализацию на примере системы SAP ERP.
Администрирование (Базис) Для реализации шаблонной части и
обеспечения возможности дальнейшего развития системы необходимо
корректно выстроить системный ландшафт. По методологии САП
стандартно предполагается трехуровневая структура (стрелками показаны
маршруты переносов обновлений (запросов) системы) – рисунок 2.1.
Рисунок 2.1 - Система разработки → Система тестирования →
Система продуктивная
44
В ходе разрабатывания проекта производятся определенные
настройки и разработки (происходит процесс перепрограммирования). Все
внесенные разработчиками модификации транспортируются (при помощи
механизмов транспортировки запроса) в мандант тестирования программы,
в которой и производится контролирование качества. После получения
положительных результатов тестирования запросы переносятся в
продуктивную систему для использования в текущей работе. В случае если
в результате проекта сформировано шаблонное решение, необходимо
обеспечить возможность раздельной реализации и тестирования локальной
части между организациями. Данное требование возможно обеспечить,
разделив системы разработки и тестирования между локальными и
шаблонной частями – рисунок 2.2.
Рисунок 2.2 - Система разработки (шаблон/типовое) → Система
тестирования (шаблон/ типовое) → Система разработки
(локальное/типовое) → Система тестирования (локальное)→ Система
продуктивная
45
Данная реализация на системном уровне обеспечит возможность
сохранения единства шаблонного решения, а также облегчит контроль за
вносимыми изменениями в шаблонную часть. Но необходимо понимать,
что контроль решений в части методологии необходимо реализовать, так
как имеются прецеденты расхождения решений в части бизнес-процессов,
реализованных в одном ландшафте за счет параллельной реализации в
системе [18, с. 69].
В случае если шаблонная часть реализуется в параллельных
ландшафтах (по сути, повторение шаблонных настроек в технически
различных системах настройки), это гарантированно приведет к
расхождению в решениях реализации рисунок 2.3.
Рисунок 2.3 - Система разработки 1 → Система тестирования 1
→ Система продуктивная 1 / Система разработки N → Система
тестирования N → Система продуктивная N
46
В взаимосвязи с ведением исследований и настроек одновременно,
то что исполняется ручным способом. ant. автоматический (или с
неполными переносами с смежных режимов), этот аспект, безусловно, в
результате повергнет к расхождениям в опциях концепций.
Разработка (формируемые мощностями разработчиков программного
обеспечения проекты присутствие введении и компании) присутствие
трафаретном постановлении реализовывается последующими методами, в
случае в случае если:
• в случае в случае если создание конкретно принадлежит к
шаблонным/типовым действиям, в таком случае реализуется один раз с
целью абсолютно всех концепций;
• в случае в случае если создание конкретно принадлежит к местным
действиям, в таком случае реализуется в согласовании с условиями
определенных концепций числом, одинаковым концепциям;
• в случае в случае если исследование конкретно невозможно
систематизировать согласно взаимоотношению к предпринимательство-
действиям, вероятно применение в коде проекты специализированных
модулей-подпрограмм (user-exit, enhancement point, BADI, open-fi) или их
аналогов присутствие программировании, для того чтобы сберечь
околоодной проектом вероятность осуществлении стандартной и местной
элементов с учетом исследования в разных концепциях исследования.
Для разделения опций (customizing) в концепции имеется обычный
система – структура предпринимательство-опций(Business Configuration
Sets (BC Sets). Этот механизм дает возможность классифицировать
юстировочные воззрению(таблицы, воззрению таблицы или конкретные
значимости) в конструкции в мишенях концентрированного перенесения, а
кроме того предоставления способности разделения согласно
возможностям к стандартным опциям [38, с. 78].
Существует 2 типа BC Sets:
47
Sets.
• Элементарные BC Sets (именуемые «BC Sets»). • Иерархические BC
Простой BC Sets включает сведения с таблиц опций (customizing).
Сведения избираются с строчек и столбиков таблиц. В этом случае не
имеется ограничений согласно объему.
Каждая транзакция настройки указана отдельно с указанием
объектов (таблицы (tables) или представления (views) (см. рисунок 2.4).
Рисунок 2.4 - Простые BC Sets
Иерархический BC Sets включает в себя несколько других BC Sets,
которые также могут быть иерархическими.
Иерархия может иметь любое количество уровней, что позволяет
включать структуры сложной системы настройки данных. Возможно
48
удаление или добавление уровней BC Sets без ограничений (см. рисунок
2.5).
Рисунок 2.5 - Иерархические BC Sets
Данные BC Sets возможно переносить механизмом транспортировки
запросов по системам, тем самым обеспечивая непротиворечивость
настроек, входящих в BC Sets.
Для сокращения затрат на внедрение и сопровождение
информационной системы SAP ERP оптимальным подходом является
использование шаблонных решений для организаций, имеющих в своем
составе несколько дочерних обществ, в том числе имеющих различные
методологии ведения учета.
Процесс шаблонизации – по сути, это стандартизация процессов
предприятия, что позволяет уменьшать количество вариаций при
49
внедрении системы и соответственно снижает количество разработок и
настроек при последующем сопровождении. Для проведения работ по
шаблонизации необходимо прямое участие владельцев БП КУ для
принятия решений в случае различных подходов в имеющихся
реализациях систем. Приведенный краткий анализ показывает
возможности шаблонных решений и способы их реализации и
дальнейшего сопровождения.
2.3. Организационная структура и состав пользователей.
Как уже пояснялось выше, в Продуктивной системе Ландшафта SAP
ERP хранятся данные о пользователях программы.
Роль (отдельная) - описывает, какие именно действия может
осуществлять пользователь в системе.
Роль (групповая) - состоит из отдельных ролей. Используется для
облегчения работы с ролями [29, с. 110].
Роли являются мандантозависимыми, создаются и переносятся так
же, как настройки. Роль может содержать в себе:
1) дополнение к меню пользователя, т.е., транзакции с названиями,
которые будет видеть пользователь;
2) объекты полномочий - описывают, что именно может делать
пользователь. Например, какие транзакции он имеет право запускать,
какие именно операции над данными может выполнять для данного
подразделения и т.п.
Следует иметь в виду, что если пользователю присвоены несколько
ролей, в которых есть один и тот же объект полномочий с разными
параметрами, пользователь получит максимальные права из двух
возможных (соответствует логической операции "или"). На программном
уровне объект полномочий является специальным элементом языка
ABAP/4 и проверяется при выполнении программы. В зависимости от
50
результатов проверки программа может осуществлять различные действия,
например, выдавать сообщение "Недостаточно полномочий".
Профиль полномочий - это скомпилированная (приведенная в
машинный вид) роль. Собственно система работает именно с профилями,
роли пользователю можно и не присваивать (если нет нужды в меню).
Группы пользователей:
Группы пользователей по функционалу/приложениям
Всех пользователей SAP ERP можно разделить на группы в
соответствии с их функционалом, какие модули программы они
используют, к каким отделам обращаются, с какой информацией работают.
В зависимости от этого можно настроить доступ к той или иной
информации – рисунок 2.6.
Рисунок 2.6 - Иерархические BC Sets
51
Группы пользователей по контенту: администраторы, разработчики
и пользователи.
Специальные группы (по проектам): рисунок 2.7.
Рисунок 2.7 - Проектные группы
Группы пользователей для ограничения доступа к данных, с их
помощью защищается конфиденциальность требуемых данных.