Использование сппр в ит компании для руководителя компании

Содержание:

1.     Кому пригодится 1С СППР
2.     Какие функции перекрывает Система проектирования прикладных решений
3.     Главный плюс 1С СППР  

1.     Кому пригодится 1С СППР

Многие на стадии инициации проекта задумываются о применении ПО для контроля за ведением проекта и контроля качества проектной документации. И, зачастую, таким решением видится 1С:Система проектирования прикладных решений. Необходимо понимать, что на небольшие проекты использование 1С СППР только усложнит жизнь проектной команде. Но если у вас планируется крупный проект с множеством доработок, где необходимо постоянное взаимодействие между архитекторами, программистами, аналитиками и методологами — эта система для вас.  

2.     Какие функции перекрывает система проектирования прикладных решений

Итак, какие же функции перекрывает система проектирования прикладных решений:

·        Моделирование

Модель вашей будущей системы может быть связана с моделью бизнес-процессов в нотации IDEF0. Также модель будет связана с метаданными и алгоритмами 1С 8.3. В 1С СППР может быть предусмотрена интеграция со средами моделирования. Проработка архитектуры конфигурации на основе модели упрощается, так как все метаданные в 1С 7.7 подгружаются из конфигурации в самом процессе её создания. Также в 1С СППР возможно настроить правила проверки функциональной модели в режиме Предприятие 1С 7.

·        Работа проектной команды

Формализация требований, работа с ними, связь требований с объектами метаданных 1С 7.7 системы, работа с ошибками, управление изменениями. Для руководителя проектов 1С СППР является мощным инструментом ведения технических проектов.

·        Документирование

Документация будет тесно связана с моделью. В случае крупных проектов документация может исчисляться томами. 1С СППР в десятки раз упрощает документационные процессы, например, описание метаданных той или иной конфигурации.

·        Разработка.

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

3.     Главный плюс 1С СППР

Главный плюс 1С СППР — ведение всего проекта в системе, учет истории изменений, фиксация действий проектной команды. В системе хранится история изменений объектов метаданных, а также версионирование объектов. В дальнейшем, на этапе поддержки разработанного решения, будет в разы проще отследить все метаданные и проводить обновления/доработки готового продукта. По всем объектам метаданных можно отследить, когда и зачем он был сделан. 

Из всего вышеописанного делаем вывод, что 1С СППР полезный и развивающийся продукт, помогающий существенно упростить жизнь проектной команде.

Специалист компании «Кодерлайн»

Удалова Кристина

Библиографическое описание:

Жаманкарин, Максут Мухамбетназарулы. Основные направления систем информационной поддержки руководителя предприятия / Максут Мухамбетназарулы Жаманкарин, Арман Сагатулы Кабдушев. — Текст : непосредственный // Молодой ученый. — 2015. — № 8 (88). — С. 139-141. — URL: https://moluch.ru/archive/88/17148/ (дата обращения: 22.03.2023).

В данной статье рассматривается система поддержки принятия решений.

Система поддержки принятия решений (СППР) — компьютерная автоматизированная система, целью которой является помощь людям, принимающим решение в сложных условиях для полного и объективного анализа предметной деятельности. СППР возникли в результате слияния управленческих информационных систем и систем управления базами данных [1].

Система поддержки принятия решений предназначена для поддержки многокритериальных решений в сложной информационной среде. При этом под многокритериальностью понимается тот факт, что результаты принимаемых решений оцениваются не по одному, а по совокупности многих показателей (критериев) рассматриваемых одновременно. Информационная сложность определяется необходимостью учета большого объема данных, обработка которых без помощи современной вычислительной техники практически невыполнима. В этих условиях число возможных решений, как правило, весьма велико, и выбор наилучшего из них, без всестороннего анализа может приводить к грубым ошибкам. Система поддержки решений СППР решает две основные задачи [3]:

1)                 выбор наилучшего решения из множества возможных (оптимизация);

2)                 упорядочение возможных решений по предпочтительности (ранжирование).

В обеих задачах первым и наиболее принципиальным моментом является выбор совокупности критериев, на основе которых в дальнейшем будут оцениваться и сопоставляться возможные решения (будем называть их также альтернативами). Система СППР помогает пользователю сделать такой выбор. Для анализа и выработок предложений в СППР используются разные методы. Это могут быть [2]:

1)                 информационный поиск;

2)                 интеллектуальный анализ данных;

3)                 поиск знаний в базах данных;

4)                 рассуждение на основе прецедентов;

5)                 имитационное моделирование;

6)                 эволюционные вычисления и генетические алгоритмы;

7)                 нейронные сети;

                 ситуационный анализ;

9)                 когнитивное моделирование и др.

Некоторые из этих методов были разработаны в рамках искусственного интеллекта. Если в основе работы СППР лежат методы искусственного интеллекта, то говорят об интеллектуальной СППР или ИСППР. Близкие к СППР классы систем — это экспертные системы и автоматизированные системы управления. Система позволяет решать задачи оперативного и стратегического управления на основе учетных данных о деятельности компании. Система поддержки принятия решений представляет собой комплекс программных инструментальных средств для анализа данных, моделирования, прогнозирования и принятия управленческих решений, состоящий из собственных разработок корпорации и приобретаемых программных продуктов. Классификации СППР. По взаимодействию с пользователем выделяют три вида СППР [4]:

1)                 пассивные помогают в процессе принятия решений, но не могут выдвинуть конкретного предложения;

2)                 активные непосредственно участвуют в разработке правильного решения;

3)                 кооперативные предполагают взаимодействие СППР с пользователем.

Выдвинутое системой предложение пользователь может доработать, усовершенствовать, а затем отправить обратно в систему для проверки. После этого предложение вновь представляется пользователю, и так до тех пор, пока он не одобрит решение. По способу поддержки различают [5]:

1)                 модельно-ориентированные СППР, используют в работе доступ к статистическим, финансовым или иным моделям;

2)                 СППР, основанные на коммуникациях, поддерживают работу двух и более пользователей, занимающихся общей задачей;

3)                 СППР, ориентированные на данные, имеют доступ к временным рядам организации. Они используют в работе не только внутренние, но и внешние данные;

4)                 СППР, ориентированные на документы, манипулируют неструктурированной информацией, заключенной в различных электронных форматах;

5)                 СППР, ориентированные на знания, предоставляют специализированные решения проблем, основанные на фактах.

По сфере использования выделяют [1]:

1)                 общесистемные

2)                 настольные СППР.

Общесистемные работают с большими СХД и применяются многими пользователями. Настольные являются небольшими системами и подходят для управления с персонального компьютера одного пользователя [6].

Литература:

1.         Ларичев О. И., Петровский А. В. Системы поддержки принятия решений. Современное состояние и перспективы их развития. // Итоги науки и техники. Сер. Техническая кибернетика. — Т.21. М.: ВИНИТИ, 1987, С. 131–164

2.         Сараев А. Д., Щербина О. А. Системный анализ и современные информационные технологии //Труды Крымской Академии наук. — Симферополь: СОНАТ, 2006. — С. 47–59

3.         Терелянский, П. В. Системы поддержки принятия решений. Опыт проектирования: монография / П. В. Терелянский; ВолгГТУ. — Волгоград, 2009. — С.101–127

4.         Автоматизация управлением предприятием / Баронов В. В. и др. М.: Инфра-М, 2000. — С.198–205.

5.         Автоматизированное проектирование информационно-управляющих систем. Системное моделирование предметной области: Учебное пособие / Г. Г. Куликов, А. Н. Набатов, А. В. Речкалов. Уфа: УГАТУ, 1998.- С.89–104.

6.         Клиланд Д., Кинг В. Системный анализ и целевое управление. -М.:Сов.радио, 1979. С.5–11.

Интеллектуальные системы поддержки принятия решений — краткий обзор

Дисклеймер

Целью написания этой статьи было сделать краткий обзор принципов построения Интеллектуальных Систем Поддержки Принятия Решений (ИСППР), роли машинного обучения, теории игр, классического моделирования и примеров их использования в СППР. Целью статьи не является забуриться вглубь тяжелой теории автоматов, самообучаемых машин, равно как и инструментов BI.

Введение

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

Зачем нужны СППР:

1. Сложность в принятии решений
2. Необходимость в точной оценке различных альтернатив
3. Необходимость предсказательного функционала
4. Необходимость мультипотокового входа (для принятия решения нужны выводы на основе данных, экспертные оценки, известные ограничения и т.п.)

Первые СППР (тогда еще без И) выросли из СПТ (Систем Процессинга Транзакций), в середине 60-х — начале 70-х. Тогда эти системы не обладали никакой интерактивностью, представляя собой, по сути, надстройки над РСУБД, с некоторым (совсем не большим) функционалом численного моделирования. Одной из первых систем можно назвать DYNAMO, разработанную в недрах MIT и представлявшую собой систему симуляции каких-либо процессов на основе исторических транзакций. После выхода на рынок мейнфреймов IBM 360 стали появляться и условно-коммерческие системы, применявшиеся в оборонке, спецслужбах и НИИ.

С начала 80-х уже можно говорить о формировании подклассов СППР, таких как MIS (Management Information System), EIS (Executive Information System), GDSS (Group Decision Support Systems), ODSS (Organization Decision Support Systems) и др. По сути, эти системы представляли собой фреймворки, спососбные работать с данными на различных уровнях иерархии (от индивидуального до общеорганизационного), а внутрь можно было внедрить какую угодно логику. Примером может служить разработанная Texas Instruments для United Airlines система GADS (Gate Assignment Display System), которая поодерживала принятие решений в Field Operations — назначение гейтов, определение оптимального времени стоянки и т.п.

В конце 80-х появились ПСППР (Продвинутые — Advanced), которые позволяли осуществлять «what-if» анализ и использовали более продвинутый инструментарий для моделирования.

Наконец, с середины 90-х на свет стали появляться и ИСППР, в основе которых стали лежать инструменты статистики и машинного обучения, теории игр и прочего сложного моделирования.

Многообразие СППР

На данных момент существует несколько способов классификации СППР, опишем 3 популярных:

По области применения

• Бизнес и менеджмент (прайсинг, рабочая сила, продукты, стратегия и т.п.)
• Инжиниринг (дизайн продукта, контроль качества…)
• Финансы (кредитование и займы)
• Медицина (лекарства, виды лечения, диагностика)
• Окружающая среда

По соотношению данныемодели (методика Стивена Альтера)

• FDS (File Drawer Systems — системы предоставления доступа к нужным данным)
• DAS (Data Analysis Systems — системы для быстрого манипулирования данными)
• AIS (Analysis Information Systems — системы доступа к данным по типу необходимого решения)
• AFM(s) (Accounting & Financial models (systems) — системы рассчета финансовых последствий)
• RM(s) (Representation models (systems) — системы симуляции, AnyLogic как пример)
• OM(s) (Optimization models (systems) — системы, решающие задачи оптимизации)
• SM(s) (Suggestion models (systems) — системы построения логических выводов на основе правил)

По типу использумого инструментария

• Model Driven — в основе лежат классические модели (линейные модели, модели управления запасами, транспортные, финансовые и т.п.)
• Data Driven — на основе исторических данных
• Communication Driven — системы на оснвое группового принятия решений экспертами (системы фасилитации обмена мнениями и подсчета средних экспертных значений)
• Document Driven — по сути проиндексированное (часто — многомерное) хранилище документов
• Knowledge Driven — внезапно, на основе знаний. При чем знаний как экспертных, так и выводимых машинно

Я требую жалобную книгу! нормальную СППР

Несмотря на такое многообразие вариантов классификаций, требования и атрибуты СППР хорошо ложатся в 4 сегмента:

1. Качество
2. Организация
3. Ограничения
4. Модель

На схеме ниже покажем, какие именно требовани и в какие сегменты ложаться:

Отдельно отметим такие важные атрибуты, как масштабируемость (в ныне одном подходе agile никуда без этого), способность обрабатывать плохие данные, юзабилити и user-friendly interface, нетребовательность к ресурсам.

Архитектура и дизайн ИСППР

Существет несколько подходов к тому, как архитектурно представить СППР. Пожалуй, лучшее описание разности подходов — «кто во что горазд». Несмотря на разнообразие подходов, осуществляются попытки создать некую унифицированную архитектуру, хотя бы на верхнем уровне.

Действительно, СППР вполне можно разделить на 4 больших слоя:

1. Интерфейс
2. Моделирование
3. Data Mining
4. Data collection

А уж в эти слои можно напихать какие угодно инструменты.

На схеме ниже представляю мое видение архитектуры, с описанием функционала и примерами инструментов:

С архитектурой более или менее понятно, перейдем к дизайну и собственно построению СППР.

В прицнипе, тут нет никакого rocket science. При построении ИСППР необходимо придерживаться следующих шагов:

1. Анализ домена (собственно, где мы будем нашу ИСППР использовать)
2. Сбор данных
3. Анализ данных
4. Выбор моделей
5. Экспертный анализинтерпретация моделей
6. Внедрение моделей
7. Оценка ИСППР
8. Внедрение ИСППР
9. Сбор обратной свзяи (на любом этапе, на самом деле)

На схеме это выглядит так:

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

Подчеркну, что это только ИМХО и вы можете сами сделать удобный для себя чек-лист.

А где тут машинное обучение и теория игр?

Да практически везде! По крайней мере в слое, связанном с моделированием.

С одной стороны, есть классические домены, назовем их «тяжелыми», вроде управления цепями поставок, производства, запасов ТМЦ и проч. В тяжелых доменах наши с вами любимые алгоритмы могут привнести дополнительные инсайты для зарекомендовавших себя классических моделей. Пример: предиктивная аналитика по выходам из строя оборудования (машинное обучение) отлично сработается с каким-нибудь FMEA анализом (классика).

С другой стороны, в «легких» доменах, вроде клиентской аналитики, предсказании churn, выплаты кредитов — алгоритмы машинного обучения будут на первых ролях. А в скоринге, например, можно совмещать классику с NLP, когда решаем выдавать ли кредит на основе пакета документов (как раз-таки document driven СППР).

Классические алгоритмы машинного обучения

Допустим, есть у нас задачка: менеджеру по продажам стальной продукции надо еще на этапе получения заявки от клиента понимать, какого качества готовая продукция поступит на склад и применить некое управляющее воздействие, если качество будет ниже требуемого.

Поступаем очень просто:

Шаг 0. Определяем целевую переменную (ну, например, содержание оксида титана в готовой продукции)
Шаг 1. Определяемся с данными (выгружаем из SAP, Access и вообще ото всюду, куда дотянемся)
Шаг 2. Собираем фичигенерим новые
Шаг 3. Рисуем процесс data flow и запускаем его в продакшн
Шаг 4. Выбираем и обучаем модельку, запускаем ее крутиться на сервере
Шаг 5. Определяем feature importances
Шаг 6. Определяемся со вводом новых данных. Пусть наш менеджер их вводит, например, руками.
Шаг 7. Пишем на коленке простой web-based интерфейс, куда менеджер вводит ручками значения важных фич, это крутится на серваке с моделькой, и в тот же интерфейс выплевываестя прогнозируемое качество продукции

Вуа-ля, ИСППР уровня детсад готова, можно пользоваться.

Подобные «простые» алгоритмы также использует IBM в своей СППР Tivoli, которая позволяет определять состояние своих супер-компьютеров (Watson в первую очередь): на основе логов выводится информация по перформансу Watson, прогнозируется доступность ресурсов, баланс cost vs profit, необходимость обслуживания и т.п.

Компания ABB предлагает своим клиентам DSS800 для анализа работы электродвигателей той же ABB на бумагоделательной линии.

Финская Vaisala, производитель сенсоров для минтранса Финляндии использует ИСППР для предсказания того, в какие периоды необходимо применять анти-обледенитель на дорогах во избежания ДТП.

Опять-таки финская Foredata предлагает ИСППР для HR, которая помогает принимать решения по годности кандидата на позицию еще на этапе отбора резюме.

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

Тысячи их!

Обычные нейронные сети

Кроме простого ML, в СППР отлично ложится и Deep Learning.

Некоторые примеры можно найти в ВПК, например в американской TACDSS (Tactical Air Combat Decision Support System). Там внутри крутятся нейронки и эволюционные алгоритмы, помогающие в определении свой-чужой, в оценке вероятности попадания при залпе в данный конкретный момент и прочие задачки.

В немного более реальном мире можно рассмотреть такой пример: в сегменте B2B необходимо определить, выдавать ли кредит организации на основе пакета документов. Это в B2C вас оператор замучает вопросами по телефону, проставит значения фич у себя в системе и озвучит решение алгоритма, в B2B несколько посложнее.

ИСППР там может строиться так: потенциальный заемщик приносит заранее согласованный пакет документов в офис (ну или по email присылает сканы, с подписями и печатями, как положено), документы скармливаются в OCR, затем передаются в NLP-алгоритм, который дальше уже делит слова на фичи и скармливает их в NN. Клиента просят попить кофе (в лучшем случае), или

вот где карту оформляли туда и идите

прийти после обеда, за это время как раз все и обсчитается и выведет на экран девочке-операционисту зеленый или красный смайлик. Ну или желтый, если вроде ок, но нужно больше справок богу справок.

Подобными алгоритмами пользуются также в МИД: анкета на визу + прочие справки анализируются прямо в посольстве консульстве, после чего сотруднику на экране высвечивается один из 3 смайликов: зеленый (визу выдать), желтый (есть вопросы), красный (соискатель в стоп-листе). Если вы когда-нибудь получали визу в США, то то решение, которое озвучивает вам сотрудник консульства — это именно результат работы алгоритма в совокупности с правилами, а никак не его личное субъективное мнение о вас:)

В тяжелых доменах известны также СППР на основе нейронок, определяющие места накопления буфера на производственных линиях (см, напимер, Tsadiras AK, Papadopoulos CT, O’Kelly MEJ (2013) An artificial neural network based decision support system for solving the buffer allocation problem in reliable production lines. Comput Ind Eng 66(4):1150–1162), Общие Нечеткие Нейронные Сети на основе мин-макса (GFMMNN) для кластеризации потребителей воды (Arsene CTC, Gabrys B, Al-Dabass D (2012) Decision support system for water distribution systems based on neural networks and graphs theory for leakage detection. Expert Syst Appl 39(18):13214–13224) и другие.

Вообще стоит отметить, что NN как нельзя лучше подходят для принятия решений в условиях неопределенности, т.е. условиях, в которых и живет реальный бизнес. Алгоритмы кластеризации также хорошо вписались.

Байесовские сети

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

Динамические данные обновляются во времени, соответственно, паттерн работы модели будет такой: обучение-решение-обучение, что в общем похоже на работу врача: примерно определить диагноз, прокапать лекарство, посмотреть за реакцией. Таким образом, мы постоянно пребываем в состоянии неопределенности, подействует лечение или нет. И состояние пациента меняется динамически. Т.е. нам надо построить динамическую СППР, причем еще и knowledge driven.

В таких случаях нам отлично помогут Динамические Байесовские Сети (ДБС) — обобщение моделей на основе фильтров Калмана и Скрытой Марковской Модели.

Разделим данные по пациенту на статические и динамические.

Если бы мы строили статическую байесовскую сетку, то нашей задачей было бы посчитать следующую вероятность:

,

где — узел нашей сетки (вершина графа, по сути), т.е. значение каждой переменной (пол, возраст….), а С — предсказываемый класс (болезнь).

Статическая сетка выглядит так:

Но это не айс. Состояние пациента меняется, время идет, надо решать, как же его лечить.

Вот для этого и применим ДБС.

Сначала, в день приема пацитента, строим статическую сетку (как на картинке выше). Потом, в каждый день i строим сетку на основе динамически меняющихся данных:

Соответственно, совокупная модель примет следующий вид:

Таким, образом, результат мы расчитаем по следующей формуле:

, где T — совокупное время госпитализации, N — количество переменных на каждом из шагов ДБС.

Внедрить эту модель в СППР необходимо несколько иначе — скорее тут надо идти от обратного, сначала эту модель зафиксировать, а потом строить интерфейс вокруг. Т.е., по сути, мы сделали хард модель, внутри которой динамические элементы.

Теория игр

Теория игр, в свою очередь, гораздо лучше подойдет для ИСППР, созданных для принятия стратегических решений. Приведем пример.

Допустим, на рынке существует олигополия (малое количество соперников), есть определенный лидер и это (увы) не наша компания. Нам необходимо помочь менеджменту принять решение об объемах выпускаемой нами продукции: если мы будем выпускать продукцию в объеме , а наш соперник — , уйдем мы в минус или нет? Для упрощения возьмем частный случай олигополии — дуополию (2 игрока). Пока вы думаете, RandomForest тут или CatBoost, я вам предложу использовать классику — равновесие Штакельберга. В этой модели поведение фирм описывается динамической игрой с полной совершенной информацией, при этом особенностью игры является наличие лидирующей фирмы, которая первой устанавливает объём выпуска товаров, а остальные фирмы ориентируются в своих расчетах на неё.
Для решения нашей задачи нам надо всего-то посчитать такое , при котором решится задача оптимизации следующего вида:

Для ее решения (сюрприз-сюрприз!) надо лишь приравнять первую производную по к нулю.

При этом для такой модели нам понадобится знать только предложение на рынке и стоимость за товар от нашего конкурента, после чего построить модель и сравнить получившееся q с тем, которое хочет выкинуть на рынок наш менеджмент. Согласитесь, несколько проще и быстрее, чем пилить NN.

Для таких моделей и СППР на их основе подойдет и Excel. Конечно, если вводимые данные надо посчитать, то нужно что-то посложнее, но не сильно. Тот же Power BI справится.

Искать победителя в битве ML vs ToG бессмысленно. Слишком разные подходы к решению задачи, со своими плюсами и минусами.

Что дальше?

С современным состоянием ИСППР вроде бы разобрались, куда идти дальше?

В недавнем интервью Джуда Перл, создатель тех самых байесовских сетей, высказал любопытное мнение. Если слегка перефразировать, то

«все, чем сейчас занимаются эксперты в машинном обучении, это подгонка кривой под данные. Подгонка нетривиальная, сложная и муторная, но все-таки подгонка.»

(почитать)

Скорее всего, вангую, через лет 10 мы перестанем жестко хардкодить модели, и начнем вместо этого повсеместно обучать компьютеры в создаваемых симулируемых средах. Наверное, по этому пути и пойдет реализация ИСППР — по пути AI и прочих скайнетов и WAPR’ов.

Если же посмотреть на более близкую перспективу, то будущее ИСППР за гибкостью решений. Ни один из предложенных способов (классические модели, машинное обучение, DL, теория игр) не универсален с точки зрения эффективности для всех задач. В хорошей СППР должны сочетаться все эти инструменты + RPA, при этом разные модули должны использоваться под разные задачи и иметь разные интерфейсы вывода для разных пользователей. Этакий коктейль, смешанный, но ни в коем случае не взболтанный.

Литература

1. Merkert, Mueller, Hubl, A Survey of the Application of Machine Learning in Decision Support Systems, University of Hoffenhaim 2015
2. Tariq, Rafi,Intelligent Decision Support Systems- A Framework, India, 2011
3. Sanzhez i Marre, Gibert, Evolution of Decision Support Systems, University of Catalunya, 2012
4. Ltifi, Trabelsi, Ayed, Alimi, Dynamic Decision Support System Based on Bayesian Networks, University of Sfax, National School of Engineers (ENIS), 2012

Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы — это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создается новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются.

В этом случае формальный процесс проектирования навряд ли имеет смысл. Речь идет именно о формализации процесса, т.к. сам процесс проектирования является неотъемлемой частью разработки и конечно будет присутствовать, пусть даже только в голове разработчика.

А когда проектирование имеет смысл:

1. Есть общая стратегия компании, и развитие ИТ систем – часть этой стратегии.
2. Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.
3. Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.

Ниже схематично представлены предпосылки к созданию проекта системы: 

Собственно, все начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования – ARIS, Business Studio. И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства – УSAP интегрированный ARIS, у IBM – RUP, у Microsoft – MSF, интегрированная в Visual Studio. Вот и у 1С появился собственный инструмент – 1С:СППР.

         Теперь возникает второй вопрос: «А как на практике используется 1С:СППР»? В данном случае могу рассказать только о своей личной практике. К сожалению, она может не совпадать с тем, для чего в 1С планировали 1С:СППР. В моей практике 1С:СППР использовался для следующих задач:

Из рисунка, пожалуй, все понятно – в систему заносится информация исходя из текущих моделей бизнес процессов – проектируется модель системы: процессы и функции, которые декомпозируются до уровня метаданных и алгоритмов. Далее генерируются документы – спецификации на разработку, проектные решения и даже пользовательская документация.

Стоит отметить, что в данном случае речь идет не столько об 1С:СППР, сколько о системе, которая была разработана на ее основе, путем внесения достаточно существенных модификаций. Дело в том, что первая версия 1С:СППР, когда нам требовался подобный инструмент, не отвечала нашим требованиям, да и вообще вряд ли могла отвечать чьим либо требованиям:

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

         В итоге, все функции, которые, на мой взгляд, должны лечь на 1С:СППР можно разбить на следующие 4 части:

1)    Функции моделирования

a.     Модель системы, связь с моделью БП (в разных нотациях)

b.    Связь модели системы с метаданными и алгоритмами 1С

c.     Интеграция со средами моделирования

2)    Функции коллективной работы

a.     Работа с требованиям

b.    Работа с ошибками

3)    Функции документирования

a.     Связь документации с моделью

b.    Экспорт документации в 1С и Word

4)    Функции организации разработки и тестирования

a.     Спецификации и задачи на разработку

b.    Результаты тестирования и отработки ошибок

В типовой 1С:СППР очень хорошо реализован блок (1), за исключением того, что хотелось бы конечно иметь возможность представлять модель в разных нотациях. Нам была ближе EPC, в 1С:СППР реализована только IDEF0.

Функции коллективной работы в текущей версии реализованы в полном объеме, на мой взгляд конечно, чаще всего это необходимо при работе с ошибками и требованиями.

С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР – экспорт в Word. Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ – кто как называет). А спецификация — это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами Microsoft Office. Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.

Функционала для организации разработки и тестирования в 1C:СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP – в Solution Manager есть как функционал проектирования так и полноценный Service Desk.

Собственно, данный функционал относительно СППР был доработан – основные доработки 1С:СППР касались вывода в Word и создания системы учета задач.

Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:

Итак, относительно первой версии появилось много чего интересного:

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

2)    Моделирование системы в нотации IDEF. 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC. Она в 1С:СППР, к сожалению, не реализована.

3)    Сбор требований. Функционал очень нужный на проектах.

4)    ER модель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ER диаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».

5)     Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.

6)    Есть даже инструментарий для написания справочной информации. Он не очень мощный и удобный больше вследствие ограниченности встроенного в 1С редактора текстов, но привязка справки к метаданным и экспорт справочных файлов очень удобный функционал, которым теперь можно пользоваться.

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

 Скорее всего в типовом сценарии использования, предусмотренным 1С, не подразумевается работа в системе тестировщиков и разработчиков. Так же не предусмотрено детальное описание алгоритмов.

Итак, что мы получаем от использования 1С:СППР:

1)    Разработчики отделены от проектировщиков. Best Practice из SAP welcome. Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.

2)     Генерация проектной документации.  В нашем случае ее просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.

3)    Учет задач – когда он интегрирован это очень удобно. Разработчик может сразу видеть все по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них

4)    Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.

Мы уже пошли в чем то дальше чем 1С:СППР в развитии системы, но есть вещи которых нахватает как в нашей системе так и в типовой 1С:СППР:

1)    Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.

2)    Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?

3)    Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC/IDEF.

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

Сегодня положение
дел в области применения СППР обстоит
следующим образом:

1. Непрерывно
увеличивается объем технологических
предложений, требующих высоких инвестиций,
и соответственно с усилением зависимости
от внешних услуг (например, от поставщиков
программного обеспечения). Внутрифирменные
ассигнования на нужды информационных
технологий (ИТ) растут опережающими
темпами по сравнению с другими затратами
предприятия.

2. Изменяется роль
ИТ в хозяйственной деятельности многих
предприятий. При выполнении внутрифирменных
процессов функция ИТ перестала быть
вспомогательной, превратившись в
важнейшую составную часть продукта или
производственных мощностей. Хозяйственные
риски в настоящее время во многом
определяются рисками в данной сфере.
Реализация же современных
высокопроизводительных организационных
проектов (например, «виртуальных
организаций» без жесткой привязки
производственных участков к определенному
месту), требует полного использования
потенциала ИТ с помощью телекоммуникационных
средств.

Можно выделить
шесть заинтересованных групп, от которых
зависит принятие решений в сфере ИТ:

• высшее руководство,
  которое должно управлять ИТ как
  стратегическим потенциалом предприятия;

• специалисты,
  занимающиеся поиском системных решений
  для оптимизации специальных функциональных
  задач;

• менеджеры
  отдельных хозяйственных подразделений,
  которые должны использовать ИТ в силу
  логики своей хозяйственной деятельности,
  чтобы удовлетворять запросы клиентов,
  снижать издержки и т.д.;

• менеджеры служб
  бухгалтерско-финансового учета,
  если таковые предусмотрены организационной
  структурой предприятия:

• поставщики ИТ,
  которые должны предлагать услуги в
  строгом соответствии с проблемными
  установками своих потребителей;

• собственное
  информационно-технологическое
  подразделение.

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

Предприятия
решают вопросы внедрения СППР, используя
два варианта:

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

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

Проблемы,
возникающие при внедрении СППР:

• повышение роли
  высшего менеджмента в управлении
  информационно-технологическим
  потенциалом;

• повышение знаний
  у высшего руководства фирмы в области
  ИТ, чтобы принимать компетентные
  решения, в частности в отношении
  инвестиций;

• более эффективная
  организация ИТ и использование ее в
  производстве новых товаров и услуг;

• делегирование
  функций в сфере ИТ отделам и другим
  подразделениям.

В связи с ростом
значения ИТ в обеспечении успеха
руководство должно в настоящее время
найти ответы на следующие два вопроса:

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

а) ИТ как функция
обеспечения производственного процесса,
например, в области коммуникаций или
автоматизации производства, а также
при генерации и передаче управленческих
знаний и информации для управления
хозяйственными операциями;

б) ИТ как интегральная
составная часть продукта;

в) ИТ как
организационный инструмент для создания
виртуальных форм предприятия.

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #