К какому типу входа в бизнес задачу относится программное обеспечение информационной системы

Бизнес-анализ — это структурированное изучение проблемы, имеющей отношение к бизнесу. Бизнес-анализ проводится, чтобы лучше понять проблему, а затем оценить, что требуется для ее устранения.
Бизнес-кейс/коммерческое предложение. Коммерческая цель или выгода является причиной выполнения проекта и может официально фиксироваться в документе, называющемся бизнес-кейсом, или коммерческим предложением. Этот документ обычно включает финансовые показатели (например, прирост выручки, снижение издержек и т.п.) или другие параметры (например, повышение уровня обслуживания потребителей, повышение мотивированности персонала и т.д.).

Сбор требований

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

• обязательными, т.е. без них проект будет считаться незавершенным, а заказчик останется неудовлетворенным. Если готовый продукт не соответствует всем обязательным требованиям, это — провал;
• желательными. Эти требования не обязательны, но важны для заказчика, поэтому их стараются соблюдать, за исключением тех случаев, когда они влекут за собой неприемлемое увеличение стоимости или продолжительности проекта;
• необязательными — это те требования, без которых заказчик вполне может обойтись и которые удовлетворяются только по возможности.

Выжимка по процессу формирования требований

Функциональные требования — это требования к системе.
Бизнес-требования — эквивалентно бизнес-целям.
Между ними — Пользовательские требования, User Requirements.
Пользовательские требования формулируются в терминах предметной области, а функциональные требования — в терминах системы.

Бизнес-процессы — самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. Бизнес-моделирование
2. Выявление требований
3. RUP: Анализ и проектирование, MSF: концептуальный, логический и физический дизайн
4. Реализация
5. Тестирование
6. Опытно-промышленная эксплуатация
7. Support и развитие системы

Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) — по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования — не единственный источник функциональных требований).

Типовая структура требований выглядит как «Система должна … /утверждение о необходимом функциональном поведении системы/» или «система должна позволять … /утверждение о возможности, предоставляемой пользователю или внешней системе/.

Например:
«Система должна вести журнал всех действий пользователя» или «Система должна позволять создавать новые Проекты».

Пример различий между пользовательскими и функциональными требованиями:
Пользовательское: «Система должна выводить отчеты на печать»
Функциональное: «Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги».

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM, TelelogicDoors, Rational RequisitePro) для этого есть так называемые «матрицы трассировки», на которых графически стрелками показываются зависимости между требованиями.

Важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.

Схема процесса разработки с уровнями требований

Формирование и анализ требований

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

Аттестация требований

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

Подготовка к интервью по сбору требований у заказчика

Классификация и описание требований на пути от бизнеса к технической реализации

Компания — Бизнес-требования

Источники: Топ-менеджмент компании
Документ: Бизнес-требования (обоснование потребностей инициативы)
Ответственный: Менеджер проекта

Состав бизнес-требований может отличаться на практике. Обычно включаются следующие пункты:

1. Описание контекста и списка ключевых заинтересованных лиц
2. Описание целей создания системы и критериев достижения
3. Ключевые бизнес-требования к решению и их приоритеты
4. Существующие и возможные ограничения на решение

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

Заказчик — Документ требований заинтересованных лиц

Этот документ описывает рекомендуемое содержание документа требований заинтересованных лиц:

• Бизнес-назначение
• Бизнес-рамки
• Обзор бизнеса
• Заинтересованные лица
• Организационная среда
• Цели и результаты
• Бизнес-модель
• Информационная среда
• Бизнес-процессы
• Политики и правила
• Ограничения деятельности
• Организационная структура
• Концепция использования системы
• Сценарии эксплуатации
• Проектные ограничения

Пользователь — Требования пользователя

Пользовательские требования — описание на естественном языке (плюс поясняющие диаграммы) функций, выполняемых системой, и ограничений, накладываемых на неё.
Источники: Пользователь
Документ: Пользовательские требования/Требования к ПО
Ответственный: Системный аналитик

Эти требования должны определять только внешнее поведение системы, избегая по возможности определения структурных характеристик системы. Пользовательские требования должны быть написаны естественным языком с использованием простых таблиц, а также наглядных и понятных диаграмм.

Проблемы при формировании пользовательских требований

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

Системные требования

Системные требования описывают свойства и методы всех объектов системы. Программирование – это разработка и реализация структур данных и алгоритмов. Для разработки системы программисту необходимо знать структуры данных, необходимые для реализации системы, и алгоритмы (бизнес-правила/процедуры/пакеты обработки данных), которые ими манипулируют. Системные требования — детализированное описание системных функций и ограничений, которое иногда называют функциональной спецификацией. Она служит основой для заключения контракта между покупателем системы и разработчиками ПО.
Системные требования — это более детализированное описание пользовательских требований.
Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы. Спецификация требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.

Функциональные требования

Функциональные требования — это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.

Стандартные формы для специфицирования функциональных требований:

• Описание функции или объекта.
• Описание входных данных и их источники.
• Описание выходных данных с указанием пункта их назначения.
• Указание, что необходимо для выполнения функции.
• Если это спецификация функции, необходимо описание предварительных условий (предусловий), которые должны выполняться перед вызовом функции, и описание заключительного условия (постусловия), которое должно быть выполнено после завершения выполнения функции.
• Описание побочных эффектов (если они есть).

Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».

Нефункциональных требований

Нефункциональные требования — Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой.
Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Нефункциональные требования не связаны непосредственно с функциями, выполняемыми системой. Они связаны с такими интеграционными свойствами системы, как надёжность, время ответа или размер системы. Кроме того, нефункциональные требования могут определять ограничения на систему, например на пропускную способность устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе.

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

Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:

• легкость и простота использования;
• легкость перемещения;
• целостность;
• эффективность и устойчивость к сбоям;
• внешние взаимодействия между системой и внешним миром;
• ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.

Требования предметной области

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

Требования к продукту

Требования к продукту описывают эксплуатационные свойства программного продукта. Это требования к производительности системы, объёму необходимой памяти, надёжности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.

Организационные требования

Организационные требования отображают политику и организационные процедуры заказчика и разработчика ПО. Включают стандарты разработки программного продукта, требования к реализации ПО (т.е. к языку программирования и методам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую документацию.

Требования к интеграции

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

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

Интеграция через ESB

Интеграция через ESB (Enterprise Service Bus, «Сервисная шина предприятия») применяется для обеспечения информационных систем возможностями для взаимодействия с сервисами. Использование этого метода интеграции приложений обеспечивает слабую связанность между информационными системами, так как системы взаимодействуют не напрямую, а через сервисы, размещенные на сервисной шине предприятия.
Основными функциями ESB являются:

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

Интеграция точка-точка

Интеграция приложений напрямую, является методом интеграции, при котором взаимодействие между системами происходит без применения универсального централизованного посредника, такого, как сервисная шина предприятия (ESB).

Интеграция данных

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

Задачи интеграции данных:

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

Интеграция ETL
Интеграция ETL характеризуется следующим сценарием:
На платформе ETL пишется процесс, который
1) С помощью средств доступа к БД 1ой системы забирает из таблиц 1ой системы данные
2) С помощью средств и ресурсов БД 1ой или 2й системы или своих собственных механизмов осуществляет преобразование к структурам таблиц 2й системы
3) Загружает данные в таблицы БД 2й системы.

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

Требования к пользовательскому интерфейсу

Пользовательский интерфейс — часть программной системы. Требования к пользовательскому интерфейсу могут быть разбиты на две группы:

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

К первой группе можно отнести следующие типы требований:

• Требования к размещению элементов управления на экранных формах
• Требования к содержанию и оформлению выводимых сообщений
• Требования к форматам ввода

Ко второй группе относятся следующие типы требований:

• Требования к реакции системы на ввод пользователя
• Требования к времени отклика на команды пользователя

Управление требованиями

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

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

Классификация изменяемых требований

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

Процесс управления изменениями

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

Кто читает документацию

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

Как правильно сформулировать и контролировать цель проекта?

Как и у всех путешествий, у проекта улучшения процессов должна быть цель. Если не определить конкретных целей по улучшению, люди не смогут работать согласованней, а вы не сможете сказать, есть ли движение вперед, не сможете определять приоритеты задач и сказать, когда цель достигнута.
Метрика — измеримая характеристика проекта, продукта или процесса.
Ключевые показатели производительности (KPI) — это метрики, привязанные цели и служащие мерилом продвижения проекта к достижению определенной цели или результата. Набор KPI-показателей может отображаться на контрольной панели, показывая приближение к целям.

При определении целей по совершенствованию процессов нужно иметь в виду два обстоятельства.

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

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

• Правильно ли были проанализированы проблемы и выявлены их первопричины?
• Выбрали ли вы действия по улучшению, непосредственно направленные на эти первопричины?
• Был ли реалистичным план реализации этих действий по улучшению? Был ли план реализован, как планировалось?
• Изменилось ли что-то со времени исходного анализа, что должно было заставить переориентировать действия команды по улучшению?
• Действительно ли члены команды приняли новые приемы работы и прошли период обучения, чтобы начать активно применять их на практике?
• Были ли поставлены реалистичные цели, которые команда была в состоянии достичь?

Документы процесса разработки и управления требованиями (по Вигерсу)

Высокопроизводительные проекты отличаются эффективными процессами на всех этапах создания требований: выявления, анализа, спецификации, проверки и управления. Для облегчения выполнения этих процессов каждой организации необходим набор документов процесса (process assets).
Любой процесс определяют выполняемые действия и получаемые результаты; документы процесса помогают команде выполнять процессы последовательно и эффективно. Эти документы позволяют участникам проекта понять, какие шаги им следует предпринять и каких результатов от них ждут.

Документы процесса разработки требований

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

Документы процесса управления требованиями

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

Пример дорожной карты совершенствования процессов работы с требованиями

Документ по управлению требованиями

ВВЕДЕНИЕ

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

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

Информационная система (ИС) — это система, реализующая информационную модель предметной области, чаще всего — какой-либо области человеческой деятельности. ИС должна обеспечивать: получение (ввод или сбор), хранение, поиск, передачу и обработку (преобразование) информации. [2]

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

1. ИНФОРМАЦИОННЫЕ СИСТЕМЫ

1.1 Понятие информационной системы

Понятие информационной системы интерпретируют по-разному, в зависимости от контекста.

Достаточно широкое понятие «информационная система» подразумевает, что неотъемлемыми компонентами ИС являются данные, техническое и программное обеспечение, а также персонал и организационные мероприятия.. Широко трактует понятие «информационной системы» федеральный закон Российской Федерации «Об информации, информационных технологиях и о защите информации», подразумевая под информационной системой совокупность содержащейся в базах данных информации обеспечивающих её обработку информационных технологий и технических средств. Среди российских ученых в области информатики, наиболее широкое определение ИС дает М. Р. Когаловский, по мнению которого в понятие информационной системы помимо данных, программ, аппаратного обеспечения и людских ресурсов следует также включать коммуникационное оборудование, лингвистические средства и информационные ресурсы, которые в совокупности образуют систему, обеспечивающую «поддержку динамической информационной модели некоторой части реального мира для удовлетворения информационных потребностей пользователей» [1]

Более узкое понимание информационной системы ограничивает её состав данными, программами и аппаратным обеспечением. Интеграция этих компонентов позволяет автоматизировать процессы управления информацией и целенаправленной деятельности конечных пользователей, направленной на получение, модификацию и хранение информации. Так, российский стандарт ГОСТ РВ 51987 подразумевает под ИС «автоматизированную систему, результатом функционирования которой является представление выходной информации для последующего использования». ГОСТ Р 53622-2009 использует термин информационно-вычислительнаясистема для обозначения совокупности данных (или баз данных), систем управления базами данных и прикладных программ, функционирующих на вычислительных средствах как единое целое для решения определенных задач.

В деятельности организации информационная система рассматривается как программное обеспечение, реализующее деловую стратегию организации. При этом хорошей практикой является создание и развертывание единой корпоративной информационной системы, удовлетворяющей информационные потребности всех сотрудников, служб и подразделений организации. Однако на практике создание такой всеобъемлющей информационной системы слишком затруднено или даже невозможно, вследствие чего на предприятии обычно функционируют несколько различных систем, решающих отдельные группы задач: управление производством, финансово-хозяйственная деятельность, электронный документооборот и т. д. Часть задач бывает «покрыта» одновременно несколькими информационными системами, часть задач — вовсе не автоматизирована. Такая ситуация получила название «лоскутной автоматизации» и является довольно типичной для многих предприятий. [3]

1.2 Типы информационных систем

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

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

Документальные ИС обслуживают принципиально иной класс задач, который не предполагает однозначного ответа на поставленный вопрос. Массив данных документальных ИС представляет собой совокупность неструктурированных текстовых документов. Это могут быть сборники статей, книги, рефераты и т.п. Цель такой системы — выдать список документов, в какой-то мере удовлетворяющих условиям, сформулированным запросом. Например, выдать список всех статей,в который встречается слово энтропия.

Геоинформационные системы (также ГИС — географическая информационная система) — системы, предназначенные для сбора, хранения, анализа и графической визуализации пространственных данных и связанной с ними информации о представленных в ГИС объектах. Другими словами, это инструменты, позволяющие пользователям искать, анализировать и редактировать цифровые карты, а также дополнительную информацию об объектах, например высоту здания, адрес, количество жильцов.

ГИС применяются в картографии, геологии, метеорологии, землеустройстве, экологии, муниципальном управлении, транспорте, экономике, обороне. [3]

1.3 Классификация информационных системКлассификация по архитектуре

По степени распределённости отличают:

• Настольные(desktop), или локальные ИС, в которых все компоненты (БД, СУБД, клиентские приложения) находятся на одном компьютере;

• Распределённые(distributed) ИС, в которых компоненты распределены по нескольким компьютерам.

Распределённые ИС, в свою очередь, разделяют на:

• файл-серверные ИС (ИС с архитектурой «файл-сервер»);

• клиент-серверные ИС (ИС с архитектурой «клиент-сервер»).

В файл-серверных ИС база данных находится на файловом сервере, а СУБД и клиентские приложения находятся на рабочих станциях.

В клиент-серверных ИС база данных и СУБД находятся на сервере, а на рабочих станциях находятся только клиентские приложения.

В свою очередь, клиент-серверные ИС разделяют на двухзвенные и многозвенные.

В двухзвенных (англ. two-tier) ИС всего два типа «звеньев»: сервер базы данных, на котором находятся БД и СУБД (back-end), и рабочие станции, на которых находятся клиентские приложения (front-end). Клиентские приложения обращаются к СУБД напрямую.

В многозвенных (англ. multi-tier) ИС добавляются промежуточные «звенья»: серверы приложений (application servers). Пользовательские клиентские приложения не обращаются к СУБД напрямую, они взаимодействуют с промежуточными звеньями. Типичный пример применения трёхзвенной архитектуры — современные веб-приложения, использующие базы данных. В таких приложениях помимо звена СУБД и клиентского звена, выполняющегося в веб-браузере, имеется как минимум одно промежуточное звено — веб-сервер с соответствующим серверным программным обеспечением.

Классификация по степени автоматизации

По степени автоматизации ИС делятся на:

• автоматизированные: информационные системы, в которых автоматизация может быть неполной (то есть требуется постоянное вмешательство персонала);

• автоматические: информационные системы, в которых автоматизация является полной, то есть вмешательство персонала не требуется или требуется только эпизодически.

«Ручные ИС» («без компьютера») существовать не могут, поскольку существующие определения предписывают обязательное наличие в составе ИС аппаратно-программных средств. Вследствие этого понятия «автоматизированная информационная система», «компьютерная информационная система» и просто «информационная система» являются синонимами.

Классификация по характеру обработки данных

По характеру обработки данных ИС делятся на:

• информационно-справочные, или информационно-поисковые ИС, в которых нет сложных алгоритмов обработки данных, а целью системы является поиск и выдача информации в удобном виде;

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

Классификация по сфере применения

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

• Экономическая информационная система — информационная система, предназначенная для выполнения функций управления на предприятии.

• Медицинская информационная система — информационная система, предназначенная для использования в лечебном или лечебно-профилактическом учреждении.

Классификация по охвату задач (масштабности)

• Персональная ИС предназначена для решения некоторого круга задач одного человека.

• Групповая ИС ориентирована на коллективное использование информации членами рабочей группы или подразделения.

Рис 1.Классификация информационных систем

Корпоративная ИС в идеале охватывает все информационные процессы целого предприятия, достигая их полной согласованности и прозрачности. Такие системы иногда называют системами комплексной автоматизации предприятия. [4]

2. ПРОГРАММЫ И СРЕДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ

2.1 Понятие CASE-средств

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

CASE средства (Computer — Aided Software Engineering) – это инструмент, который позволяет автоматизировать процесс разработки информационной системы и программного обеспечения. Разработка и создание информационных систем управления предприятием связаны с выделением бизнес-процессов, их анализом, определением взаимосвязи элементов процессов, оптимизации их инфраструктуры и т.д. Основной целью применения CASE средств является сокращение времени и затрат на разработку информационных систем, и повышение их качества. [5]

2.2 Классификация CASE-средств

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

Выделяют следующие группы CASE средств:

CASE средства верхнего уровня. Эти CASE средства ориентированы на начальные этапы построения информационной системы. Они связаны с анализом и планированием. CASE средства верхнего уровня обеспечивают стратегическое планирование, расстановку целей, задач и приоритетов, а также графическое представление необходимой информации. Все CASE средства верхнего уровня содержат графические инструменты построения диаграмм, таких как диаграммы сущность-связь (ER диаграммы), диаграммы потока данных ( DFD ), структурные схемы, деревья решений и пр.

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

Интегрированные CASE средства (I – CASE). Эти CASE средства охватывают полный жизненный цикл разработки информационной системы. Они позволяют обмениваться данными между инструментами верхнего и нижнего уровня и являются своего рода «мостом» между CASE средствами верхнего и нижнего уровней.

Для моделирования и оптимизации бизнес процессов применяются CASE средства верхнего уровня и интегрированные CASE средства. Они позволяют повысить качество моделей бизнес процессов за счет автоматического контроля, дают возможность оценить ожидаемый результат, ускоряют процесс проектирования, обеспечивают возможности по изменению и обновлению моделей.[5]

2.3 Характеристика CASE средств

Основными характеристиками CASE средств, важными с точки зрения моделирования и оптимизации бизнес процессов, являются следующие:

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

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

Гибкость применения. Эта характеристика дает возможность представлять бизнес процессы в различных вариантах, важных с точки зрения анализа. CASE средства должны позволять проводить анализ процессов и создавать модели, сфокусированные на различных аспектах деятельности предприятия.

Возможность коллективной работы. Анализ и моделирование процессов может требовать совместной работы нескольких человек. Для одновременной работы над моделями процессов CASE средства должны обеспечивать управление изменениями любыми фрагментами моделей и их модификацией при коллективном доступе.

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

Построение отчетов. CASE средства должны обеспечивать построение отчетов по всем моделям процессов с учетом взаимосвязи элементов. Такие отчеты необходимы для анализа моделей и определения возможностей по оптимизации. За счет отчетов обеспечивается контроль полноты и достаточности моделей, уровень декомпозиции процессов, правильность синтаксиса диаграмм и типов применяемых элементов.

2.4 Программные комплексы и технологии для создания ИС

Rational Suite. Одной из наиболее широко используемых современных технологий является Rational Unified Process (RUP), которая опирается на интегрированный комплекс инструментальных средств Rational Suite (рис.2) Rational Suite – это комплексное интегрированное решение, охватывающее весь жизненный цикл ПО и основанное на использовании самых передовых методик, инструментов и служб.

Рис 2.Программа Rational Suite

Он позволяет: объединять многофункциональные группы разработки в среде Windows с помощью интеграции основных программных продуктов и рабочего процесса; обеспечивает ускорение разработки благодаря возможностям визуального моделирования,. Обеспечивает поиск и устранение ошибок времени выполнения.[5]

AllFusion. Линейка AllFusion, разработанная компанией Computer Associates, – это семейство интегрированных решений для разработки, развертывания и управления ИС на предприятии (рис.3). Средства моделирования и инструменты управления изменениями и конфигурациями при разработке ПО позволяют организациям моделировать, разрабатывать и внедрять ИС масштаба предприятия. [5]

Рис 3. Программа AllFusion

Основные компоненты линейки AllFusion:

AllFusion Modeling Suite – интегрированный комплекс CASE- средств, включающий следующие продукты: AllFusion Process Modeler (BPwin) – функциональное моделирование; AllFusion ERwin Data Modeler (ERwin) – моделирование данных; AllFusion Component Modeler (Paradigm Plus) – объектно-ориентированный анализ и проектирование с использованием UML и возможностью генерации кода;AllFusion Model Manager (Model Mart) – организация совместной работы команды разработчиков; AllFusion Data[5]

ЗАКЛЮЧЕНИЕ

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

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

Информационная система состоит из баз данных, в которых накапливается информация, источника информации, аппаратной части информационных систем, программной части информационных систем, потребителя информации. [4]

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности ИС. Для успешной реализации ИС должна быть адекватно описана, должны быть построены полные и непротиворечивые функциональные и информационные модели системы. Это способствовало появлению программно-технологических средств специального класса – CASE-средств и различных программ. [2]

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

•  
  1. Когаловский М. Р. Перспективные технологии информационных систем. —.: ДМК Пресс; Компания АйТи, 2003. — 288 с.
  2. Блюмин А.М. Проектирование систем информационного, консультационного и инновационного обслуживания: учебное пособие / А. М. Блюмин, Л. Т. Печеная, Н. А. Феоктистов. – СПб.: Дашков и К, 2010. – 352 .[Электронный ресурс] Код доступа http://rucont.ru/efd/133972 Дата обращения 21.11.2015
  3. Электронная энциклопедия. [Электронный ресурс] Код доступа https://ru.wikipedia.org/wiki/ Дата обращения 21.11.2015
  4. Виртуальный университет. Электронный ресурс] Код доступа http://nsportal.ru/shkola/informatika-i-ikt/library/2014/04/27/ informatsionnye-sistemy-klassifikatsiya-informatsionnykh Дата обращения 21.11.2015
  5. [Электронный ресурс] Код доступа http://do.upc.omsu.ru/file.php/153/lectures/l-02.pdf. Дата обращения 21.11.2015

14

Скачать материал

Скачать материал

3.1. Программная конфигурация

Решение
любой задачи в ИС происходит по
определенному алгоритму. Алгоритм
– это точное предписание исполнителю
совершить определенную последовательность
действий для достижения поставленной
цели за конечное число шагов [30]. В
компьютерной информационной системе
алгоритм выполняется с помощью различных
программ.

Программы
– это
упорядоченные последовательности
команд, выполняемых аппаратной частью
ИС. Конечная
цель любой компьютерной программы –
управление аппаратными средствами, так
как программа работает, взаимодействуя
с оборудованием ИС [34].
Как было
показано ранее,
программное
обеспечение
(Software)
ИС
– совокупность
программ для реализации целей и задач
информационной системы, а также
нормального функционирования комплекса
технических средств.

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

Состав
программного обеспечения вычислительной
системы называют программной
конфигурацией
[34] (рис.3.1).

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

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

Базовый
уровень.
Самый низкий
уровень программного обеспечения
представляет базовое
программное обеспечение. Оно
отвечает за взаимодействие с базовыми
аппаратными средствами. Базовые
программные средства, как правило,
непосредственно входят в состав базового
оборудования и хранятся в специальных
микросхемах, называемых постоянными
запоминающими устройствами – ПЗУ (Read
Only
Memory
– ROM).
Программы и
данные записываются («прошиваются») в
микросхемы ПЗУ на этапе производства
и не могут быть изменены в процессе
эксплуатации.

Рис. 3.1

В
тех случаях, когда изменение базовых
программных средств во время эксплуатации
является технически целесообразным,
вместо микросхем ПЗУ применяют
перепрограммируемые
постоянные запоминающие устройства –
ППЗУ (Erasable
and
Programmable
Read
Only
Memory
– EPROM).
В этом случае
изменение содержания ППЗУ можно выполнять
как непосредственно в составе
вычислительной системы (такая технология
называется флэш-технологией),
так и вне ее,
на специальных устройствах, называемых
программаторами.

Набор
данных программ носит название базовой
системы ввода – вывода
(Basic
Input/Output
System
– BIOS).
BIOS
выполняет:

инициализацию
основных компонентов материнской платы
и подключенных к ней устройств;

обслуживание
системных прерываний (аппаратных и
программных), т. е. определяет режимы
взаимодействия базовых устройств;

определяет
накопитель и считывает с него в оперативное
запоминающее устройство (ОЗУ) начальный
загрузчик (Boot
Record).

Системный
уровень.
Системное
программное обеспечение управляет
всеми ресурсами ЭВМ и осуществляет
общую организацию процесса обработки
информации и интерфейс ЭВМ с проблемной
средой: с аппаратным обеспечением и с
пользователем. Поэтому программы
системного уровня можно условно разделить
на два класса. Первый класс программ
отвечает за взаимодействие с устройствами
системы. Так, например, при подключении
к вычислительной системе нового
оборудования на системном уровне должна
быть установлена программа, обеспечивающая
для других программ взаимосвязь с этим
оборудованием. Программы, отвечающие
за взаимодействие с конкретными
устройствами, называются драйверами
(Driver)
устройств,
и
они входят в состав программного
обеспечения системного уровня.

Другой
класс программ системного уровня
отвечает за взаимодействие с пользователем.
Именно благодаря им он получает
возможность вводить данные в вычислительную
систему, управлять ее работой и получать
результат в удобной для себя форме. Эти
программные средства называют средствами
обеспечения пользовательского интерфейса.
От них напрямую
зависят удобство работы с компьютером
и производительность труда на рабочем
месте.

Совокупность
программного обеспечения системного
уровня образует ядро
операционной
системы
компьютера.

Системный
уровень – переходный. Программы,
работающие на этом уровне, обеспечивают
взаимодействие остальных программ
компьютерной системы с программами
базового уровня и непосредственно с
аппаратным обеспечением, то есть
выполняют «посреднические» функции.
От программного обеспечения этого
уровня во многом зависят эксплуатационные
пока­затели всей вычислительной
системы в целом. Если компьютер оснащен
программным обеспечением системного
уровня, то он уже подготовлен к установке
программ более высоких уровней, к
взаимодействию программных средств с
оборудованием и пользователем. То есть
наличие ядра
операционной системы –
непременное
условие для возможности практической
работы человека с вычислительной
системой.

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

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

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

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

Современный
рынок ПО формируется в соответствии с
потребностями пользователей и условиями
распространения ПО.

По условиям
распространения ПО можно разделить на:

лицензионное
ПО, закупаемое у официальных дилеров –
производителей программных продуктов
и сопровождаемое ими;

свободно
распространяемое ПО (Freeware)
– большинство
файлов можно заказать по почте и
Интернету;

условно-бесплатное
(Shareware)
ПО. Условие
распространения Shareware
означает: попробуй и заплати. Поэтому
данный вид ПО обладает ограниченными
возможностями и обычно функционирует
только в течение определенного промежутка
времени.

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

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

Время на прочтение
10 мин

Количество просмотров 28K

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

И очень важно помнить при выборе и внедрении IT-систем, что первичен здесь — труд, а не программное решение. Я не единожды сталкивался с тем, что люди выбирали программу просто потому что: “она понравилась”. В результате появляются попытки “натянуть” процессное производство, например, работу молокозавода, на ERP-систему, предназначенную для дискретного производства (сборка изделий).

Самое главное правило выбора IT-систем: выбираем программу под бизнес, а не подстраиваем бизнес под понравившийся IT-продукт.

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

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

Более того, при автоматизации бизнеса понимание иерархии поможет сделать правильный выбор, определить очередность закупок и внедрения программ, избежать ошибок, результатами которых становятся невостребованные «коробки» оплаченного программного обеспечения.
Каждый продавец программных систем стремится показать свой продукт с лучшей стороны, ведь его цель – это продажа. Это необходимо учитывать при выборе системы и оценке, действительно ли продукт вам подойдет.

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

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

Классификация IT-систем

С точки зрения применения программных решений системы делятся на несколько уровней:

• Прикладные. Самый нижний уровень. Это программные решения, которые каждый сотрудник использует индивидуально на своем рабочем месте для выполнения каких-то локальных задач. Это могут быть AutoCAD, Mathcad, Photoshop, Corel Draw и т.д. Важно понимать, что прикладные системы не являются самыми простыми или самыми “плохими”, так как они находятся на нижнем уровне. Эти программные решения могут быть очень сложными, и они необходимы в работе специалистов. Нижний уровень они имеют только с точки зрения организации работы в целом, т.е. предназначены для индивидуального использования. Даже если эти продукты позволяют какую-то совместную работу, все же они предназначены, в первую очередь, для работы одного специалиста, а какие-то варианты совместного использования являются вспомогательными. а потому такие системы также относятся к прикладным.
• Системы для совместного решения определенных задач. Эти системы предназначены для решения определенных задач, относящихся к той или иной сфере деятельности. Это могут быть CRM, HR-системы, MRP, SCM-системы и пр. Каждая такая система отличается собственным узким функционалом, она предназначена для решения определенного круга специализированных задач. Программные продукты этой категории могут интегрироваться между собой или с программными решениями нижнего уровня (индивидуальными). Например, HR-системы нередко интегрируют с MS Word. А CRM интегрируются с индивидуальными программами отслеживания и записи звонков.
• ERP -системы. Программное обеспечение, предназначенное для решения самого широкого круга задач и объединения работы различных подразделений компании в единую информационную систему. ERP-системы могут включать в себя специализированные решения второго уровня (CRM, MRP, SCM и т.д.) либо могут интегрироваться со специализированными программными продуктами, предназначенными того или иного направления деятельности.
• BPMS-системы. Что это такое. я подробно писал в статье «Что такое BPMS». Кратко напомню – это непосредственно системы нотаций бизнес-процессов. Я их ставлю на самый верхний уровень иерархии по той причине, что считаю BPMS – системой организации труда в самом «чистом» виде. При этом BPMS может являться частью любых систем организации труда – как второго уровня (CRM, HR, MRP, SCM), так и третьего (ERP). Нотации BPMS встраиваются в программные продукты, тем самым позволяя стандартизировать и упростить организацию процессного подхода к организации труда.

В этой иерархии три нижних уровня программных систем – функциональные, т.е. они выполняют определенные функции. Четвертый самый высокий уровень – BPMS – исключительно процессный.

Все перечисленные выше IT-системы предназначены несут в себе определенную добавленную стоимость. Они помогают решать важные задачи.

Прикладные программы позволяют создавать какие-то продукты, например, эскизы из Photoshop на следующем этапе “превращаются” в оформление товаров, упаковки, этикетки или рекламные баннеры.

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

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

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

Почему я выбираю английские аббревиатуры и термины

Я уже в прошлых статьях писал, что предпочитаю применять английские аббревиатуры просто по той причине, что они – точнее. Кроме того, английские термины являются первичными, а русские – это различные варианты перевода.

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

Бесклассовые IT-системы

При этом все существующие системы делятся на две категории – с разработанной методологией и без нее. В случае разработанной методологии уже из названия системы становится понятно, для чего она может применяться. Примеры — CRM, MRP, HR, ERP.

В случае методологии неразработанной название также мало информативно и носит общий характер («электронный документооборот», «управление товарами», “корпоративный портал”). Главная особенность подобных программных решений заключается в том, что у них нет четкой специализации или ограничений. Они пытаются охватить как можно больше направлений деятельности, но в каждой отдельной сфере оказываются неудобными или недостаточно проработанными. Использование таких решений оправдано в определенных случаях, но, чтобы понять, подходит вам это решение или нет, придется внимательно и глубоко изучить выбранную систему. Просто исходя из названия и описания точно определить сферу применения такого продукта невозможно.

Вспомогательные IT-системы

Еще одна разновидность систем — вспомогательные. Это программные продукты, которые не влияют непосредственно на процесс организации труда. Без этих программных решений можно обойтись либо быстро найти им замену.

К этому классу относятся различные мессенджеры, системы отчетности, которые выросли в самостоятельные продукты и т.д. Эти программы являются вспомогательными. Использовать их вместо основных нельзя, хотя в определенных случаях этим грешат, преимущественно, IT-компании в стремлении продать свой продукт.

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

Как использовать иерархию на практике

Итак, мы создали определенную иерархию систем, основанную на организации труда. Самый нижний первый уровень – программы для организации работы одного человека, второй уровень – совместная специализированная работа (программное обеспечение для какого-то подразделения компании, выполняющего те или иные функции), третий уровень – работа компании в целом. И над ними – процессный подход к организации любого труда в принципе. Каким образом можно применять этот подход на практике?

Интеграция систем

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

Обратный поток данных возможен в определенных случаях, но эти исключения являются примерами ошибочной организации работы систем. В нашей стране встречаются и довольно часто решения, когда из ERP-системы данные выгружаются в бухгалтерскую систему или другой подобный продукт. Этот подход действительно применяется, но он является следствием ошибок в организации бизнес-процессов и внедрения IT-систем. В результате усложняется как работа программистов, занятых в доработках и внедрении ПО, так и организация работы всего бизнеса. Возникает ненужная путаница. А потому следует избегать такого направления. Обмен данными в две стороны нужен при интеграции между собой систем одного класса.

Например, результаты индивидуальной работы в AutoCAD или Photoshop будут отправляться, например, в MRP, CRM или ERP систему в качестве документа, на основе которого производятся расчеты, макета, отправляемого клиенту на утверждение и т.д. В обратную сторону сотруднику могут «спускаться» результаты согласования или расчетов, но в программу индивидуальной работы они не передаются. Всю информацию человек получит из системы совместной работы.

Выбор программного продукта

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

Даже разные продукты одного уровня можно попробовать сравнить, например, CRM и HR системы. Да, они отвечают за разные направления в работе. Это очевидно при самом первом сравнении. И далее вопросов обычно не возникает. А вот попытки сравнивать CRM и ERP я наблюдал не единожды. На самом деле, это так же неразумно, как сравнивать функциональные возможности MS Word и продукта другого класса, например, той же CRM.

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

Выведение внеклассовых систем

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

Внеклассовые системы – это «управление задачами», «электронный документооборот», «корпоративные порталы» и т.д. Их можно и нужно сравнивать только с им подобными внеклассовыми решениями, обладающими сходным перечнем возможностей.

Классификация программных продуктов

Программные продукты BPMS и ERP определяются очень просто. Обычно уже в названии этих систем присутствует аббревиатура, указывающая на принадлежность программы к определенному семейству. Кроме того, вы всегда можете воспользоваться перечнем признаков той или иной системы, которые я описывал в специализированных статьях: «Что такое BPMN» и «Что такое ERP».

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

Системы второго уровня (специализированные решения для совместной работы) классифицируются следующим образом:

1. Если программное решение рассчитано на совместную работу, но при этом не является ERP или BPMS, скорей всего, это специализированная система второго класса.
2. Второй шаг – проверка наличия в системе жесткой методологической основы. Если ее нет и перечень функций произволен, то это внеклассовая система. В случае, когда имеется определенная методология, функциональность и требования к подобным программным системам описаны в различной литературе (в том числе в статьях сети Интернет), назначение системы понятно уже из названия, это явно система второго класса.

Выбор специалиста для внедрения системы

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

Многие специалисты глубоко изучают какое-то прикладное программное обеспечение, после чего переключаются на учетные системы, CRM или ERP. При этом знания о прикладном обеспечении и навыки работы с ним, конечно же, никуда не денутся. В этой категории изменения в новых версиях не столь сложны и критичны, их изучение возможно по мере необходимости параллельно с другой работой. Другое дело – большие и сложные многопользовательские продукты. Здесь быть хорошим специалистов одновременно по двум и более системам – крайне сложно.

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

Классификация систем также помогает выбрать специалиста:

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

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