Информационные системы и технологии в экономике 1.2-ФК; БУ - Межвузовский информационно-образовательный портал

Межвузовский Информационно-Образовательный Портал

Demo
Demo

Информационные системы и технологии в экономике
Назад на образовательную программу


МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ - МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ СТУДЕНТАМ ПО ИЗУЧЕНИЮ ДИСЦИПЛИНЫ

Разделы

Список Литературы

  1. Киселев Г. М. Информационные технологии в экономике и управлении (эффективная работа в MS Office 2007): учебное пособие / Г. М. Киселев, Р. В. Бочкова, В. И. Сафонов. - М. : Издательско-торговая корпорация "Дашков и К°", 2013. - 272 с. - читать в библиотеке
  2. Иванов В. В. Государственное и муниципальное управление с использованием информационных технологий / В.В. Иванов, А.Н. Коробова. - М. : ИНФРА-М, 2011. - 383 с. - читать в библиотеке
  3. Сооляттэ А. Ю. Управление проектами в компании: методология, технологии, практика: учебник / А. Ю. Сооляттэ. - М. : Московский финансово-промышленный университет «Синергия», 2012. - читать в библиотеке
  4. Попов Ю. И. Управление проектами : учебное пособие / Ю.И. Попов, О.В. Яковенко ; Институт экономики и финансов "Синергия". - М. : НИЦ ИНФРА-М, 2013. - 208 с. - читать в библиотеке
  5. Управление проектами : учебное пособие / М.В. Романова. - М. : ИД ФОРУМ : НИЦ ИНФРА-М, 2014. - 256 с. - (Высшее образование). - читать в библиотеке

Ваш библиотекарь

Анатолий Вассерман

Внимание!

Для входа в Электронную Библиотеку Вам нужно получить Логин и Пароль.
Для получения Логина и Пароля ВАМ нужно обратиться в деканат Вашего института
или заполнить форму для получения:

Форма заявки






Форма контроля

  • ЭССЕ

    Темы для ЭССЕ
    "Информационные системы и технологии в экономике"
    - в данной дисциплине ЭССЕ сдавать не нужно!
  • ТЕСТ

    Бланки тестов
  • РЕФЕРАТ

    Темы для рефератов
    "Информационные системы и технологии в экономике"
    - в данной дисциплине РЕФЕРАТ писать не нужно!

Форма отправки результатов (ТЕСТ, РЕФЕРАТ)




  • captcha



ВАШ Куратор

priemzao@inyaz-mil.ru

(495) 632-00-78




Содержание разделов печать раздела -    

Введение.
верх

Лекция 1.

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

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

Информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации.

Классификация по масштабу.

По масштабу информационные системы подразделяются на следующие группы:

  • одиночные;
  • групповые;
  • корпоративные.

Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз данных.Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Qicrosoft Access. Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свободно распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Qicrosoft SQL Server, InterBase, Sybase, Inforqix. Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информационных системах наибольшее распространение получили серверы Oracle, DB2 и Qicrosoft SQL Server.

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

По сфере применения информационные системы обычно подразделяются на четыре группы:

  • системы обработки транзакций;
  • системы принятия решений;
  • информационно-справочные системы;
  • офисные информационные системы.

Системы обработки транзакций, в свою очередь, по оперативности обработки данных, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций – OLTP (OnLine Transaction Processing), для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т.п. Важными требованиями для них являются:

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

Системы поддержки принятия решений – DSS (Decision Support Systeq) – представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям. Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные систе­мы получили в сети Интернет. Класс офисных информационных систем нацелен на перевод бумажных документов в электронный вид, автоматизацию делопроизводства и управление документооборотом.

Классификация по способу организации.

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

  • системы на основе архитектуры файл-сервер;
  • системы на основе архитектуры клиент-сервер;
  • системы на основе многоуровневой архитектуры;
  • системы на основе Интернет/ интеранет-технологий.

Адекватность информации и ее формы.

Адекватность информации — это уровень соответствия образа, создаваемого с помощью информации, реальному объекту, процессу, явлению. От степени адекватности информации зависит правильность принятия решения.

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

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

Понятие вычислительной сложности.

Вычисли́тельная сло́жность — понятие в информатике и теории алгоритмов, обозначающее функцию зависимости объёма работы, которая выполняется некоторым алгоритмом, от размера входных данных. Раздел, изучающий вычислительную сложность, называется теорией сложности вычислений. Объём работы обычно измеряется абстрактными понятиями времени и пространства, называемыми вычислительными ресурсами. Время определяется количеством элементарных шагов, необходимых для решения задачи, тогда как пространство определяется объёмом памяти или места на носителе данных. Таким образом, в этой области предпринимается попытка ответить на центральный вопрос разработки алгоритмов: «как изменится время исполнения и объём занятой памяти в зависимости от размера входа?». Здесь под размером входа понимается длина описания данных задачи в битах (например, в задаче коммивояжёра длина входа почти пропорциональна количеству городов и дорог между ними), а под размером выхода — длина описания решения задачи (наилучшего маршрута в задаче коммивояжера). В частности, теория сложности вычислений определяет NP-полные задачи, которые недетерминированная машина Тьюринга может решить за полиномиальное время, тогда как для детерминированной машины Тьюринга полиномиальный алгоритм неизвестен. Обычно это сложные задачи оптимизации, например, задача коммивояжёра. С теоретической информатикой тесно связаны такие области как алгоритмический анализ и теория вычислимости. Связующим звеном между теоретической информатикой и алгоритмическим анализом является тот факт, что их формирование посвящено анализу необходимого количества ресурсов определённых алгоритмов решения задач, тогда как более общим вопросом является возможность использования алгоритмов для подобных задач. Конкретизируясь, попытаемся классифицировать проблемы, которые могут или не могут быть решены при помощи ограниченных ресурсов. Сильное ограничение доступных ресурсов отличает теорию вычислительной сложности от вычислительной теории, последняя отвечает на вопрос какие задачи, в принципе, могут быть решены алгоритмически.

Классификация автоматизированных экономических ИС.
верх

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

  • автоматизированные системы управления (АСУ);
  • системы поддержки принятия решения (СППР);
  • автоматизированные информационно-вычислительные системы (АИВС);
  • автоматизированные системы обучения (АСО);
  • автоматизированные информационно-справочные системы (АИСС).

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

В качестве объекта информатики выступает автоматизированная информационная система, представляющая собой совокупность технических программных средств и организационных мероприятий, предназначенных для автоматизации информационных процессов в профессиональной деятельности. Основным техническим средством АИС является ЭВМ. Объектом информатики является АИС, предназначенная для автоматизации военно-профессиональной деятельности должностных лиц и органов управления. Используя термин “информация”, мы, как правило, не задумываемся о том, что такое информация. Надо отметить, что вопрос этот является достаточно сложным. До настоящего времени в науке не выработано строгого определения понятия информации. Говоря об информационных процессах в АИС, мы пока будем понимать под информацией некоторую совокупность данных (текстовых, числовых, графических) и связей между ними. Под переработкой информации понимаются все возможные информационные процессы, сопровождающие профессиональную деятельность: сбор информации, хранение информации, поиск информации, представление информации на определенном носителе в определенном виде (визуальном, графическом, текстовом, звуковом), получение новой информации (например, в результате проведения расчетов), передача информации по каналам связи различным адресатам и др. Автоматизированная информационная система должна рассматриваться как инструмент в руках должностных лиц, реализующих переработку информации в процессе профессиональной деятельности. Можно сказать, что наличие этого инструмента фактически определяет новую технологию осуществления профессиональной деятельности. Понятие “технология” означает комплекс знаний о способах, приемах труда, наборах материально-технических факторов, способах их соединения для создания какого-либо продукта или услуги. Применительно к промышленному производству используется понятие “производственная индустриальная технология”. Применение понятия “технология” к информационным процессам привело к возникновению понятия “информационная технология” — совокупность знаний о способах автоматизированной переработки информации с использованием ЭВМ для автоматизации управленческой деятельности. Создание новых информационных технологий и внедрение их в профессиональную деятельность является одной из основных задач информатики. Именно поэтому в качестве предмета информатики целесообразно рассматривать информационные технологии, определяющие рациональные способы разработки и применения АИС. Каждая АИС обеспечивает реализацию некоторой информационной технологии переработки информации в процессе профессиональной деятельности. Таким образом, в качестве задач информатики можно рассматривать создание новых информационных технологий и реализующих их АИС или перенесение известных информационных технологий из одной области человеческой деятельности в другую. В качестве основного классификационного признака АИС целесообразно рассматривать особенности автоматизируемой профессиональной деятельности — процесса переработки входной информации для получения требуемой выходной информации, в котором АИС выступает в качестве инструмента должностного лица или группы должностных лиц, участвующих в управлении организационной системой. В соответствии с предложенным классификационным признаком можно выделить следующие АИС:

  • автоматизированные системы управления (АСУ);
  • системы поддержки принятия решения (СППР);
  • автоматизированные информационно-вычислительные системы (АИВС);
  • автоматизированные системы обучения (АСО);
  • автоматизированные информационно-справочные системы (АИСС).

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

Безымянный_2

Рис. Классификация АИС.

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

Системы поддержки принятия решений являются достаточно новым классом АИС, теория создания которых в настоящее время интенсивно развивается. СППР называется АИС, предназначенная для автоматизации деятельности конкретных должностных лиц при выполнении ими своих должностных (функциональных) обязанностей в процессе управления персоналом и (или) техническими средствами. Выделяются четыре категории должностных лиц, деятельность которых отличается различной спецификой переработки информации: руководитель, должностное лицо органа управления, оперативный дежурный, оператор. В соответствии с четырьмя категориями должностных лиц различают и четыре вида СППР: СППР руководителя (СППР Р), СППР должностного лица органа управления (СППР О), СППР оперативного дежурного (СППР Д) и СППР оператора (СППР Оп). Рассмотрим специфику деятельности должностных лиц, относящихся к каждой выделенной категории. К категории “руководитель” относятся должностные лица, на которых возложено управление подчиненными должностными лицами (подразделениями) и принятие решений в процессе руководства. Основная форма деятельности командира — деловое общение. Деятельность должностных лиц, относящихся к категории “руководитель”, характеризуется следующими особенностями:

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

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

  1. наличие широкой информационной базы с возможностью оперативного поиска требуемой информации;
  2. наглядность представления информации в форме, адаптированной к запросам конкретного должностного лица (текста, таблиц, графиков, диаграмм и т. д.);
  3. обеспечение оперативной связи с другими источниками информации в системе управления и особенно с непосредственными помощниками;
  4. наличие диалоговых программных средств обеспечения принятия решений на основе формальных (математических) методов;
  5. простота работы при повышенной надежности технических и программных средств;
  6. обеспечение возможности накопления в памяти ЭВМ опыта и знаний (в рамках интеллектуальных СППР).

Необходимо отметить, что требования 2, 3 и 5 являются универсальными и относятся ко всем видам СППР. В настоящее время требования 1, 2, 3 и 5 могут быть полностью удовлетворены с использованием известных информационных технологий. Что касается требований 4 и 6 (наличия программных средств обеспечения решений и накопления в памяти ЭВМ опыта и знаний), то их удовлетворение составляет основную теоретическую проблему, возникающую при создании СППР Р. К категории “должностное лицо органа управления” относятся специалисты, занимающиеся аналитической работой по подготовке решений руководителя и их документальным оформлением. Основу деятельности должностных лиц органа управления составляет оценка различных вариантов решения (проведение оценочных расчетов) и разработка проектов различных документов. Эффективность функционирования органа управления во многом определяется продуктивностью деятельности специалистов, особенно в вопросах создания новой информации. Доля творческого труда в их работе достаточно высока. Именно эти специалисты обеспечивают практически всю информационную подготовку для принятия решения руководителем. Они являются основными исполнителями документов, определяя их качество. СППР О должна прежде всего создать должностным лицам условия для плодотворного ведения аналитической работы и сведения к минимуму доли рутинных работ (поиск информации, оформление документов, проведение оперативных расчетов и т. д.).

Особенности деятельности должностных лиц органа управления определяют следующие основные требования к СППР О:

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

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

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

Перечисленные особенности деятельности оперативных дежурных определяют в качестве основных требований к СППР Д обеспечение оперативного предоставления информации, необходимой оперативному дежурному в заранее определенных ситуациях, а также обеспечение оперативного анализа складывающейся ситуации. Последнее требование может быть обеспечено с использованием технологии экспертных систем. К категории “оператор” могут быть отнесены должностные лица, выполняющие техническую работу по заранее определенному алгоритму. Основная особенность деятельности оператора — отсутствие необходимости принимать сложные решения в процессе своей деятельности. СППР Оп должна обеспечивать возможность работы должностного лица со справочной информацией и возможность автоматизированной подготовки текстов документов. Автоматизированные информационно-вычислительные системы предназначены для решения сложных в математическом отношении задач, требующих больших объемов самой разнообразной информации. Таким образом, видом деятельности, автоматизируемом АИВС, является проведение различных (сложных и “объемных”) расчетов. Эти системы используются для обеспечения научных исследований и разработок, а также как подсистемы АСУ и СППР в тех случаях, когда выработка управленческих решений должна опираться на сложные вычисления.

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

  • Информационно-расчетная система (ИРС) — это автоматизированная система, предназначенная для обеспечения оперативных расчетов и автоматизации обмена информацией между рабочими местами в пределах некоторой организации или системы организаций. ИРС обычно сопрягается с АСУ и в рамках последней может рассматриваться как ее подсистема.
  • Технической базой ИРС являются, как правило, сети больших, малых и микроЭВМ. ИРС имеют сетевую структуру и могут охватывать несколько десятков и даже сотен рабочих мест различных уровней иерархии. Основной сложностью при создании ИРС является обеспечение высокой оперативности расчетов и обмена информации в системе при строгом разграничении доступа должностных лиц к служебной информации.

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

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

  • Моделирующие центры (МЦ) — автоматизированные информационные системы, представляющие собой комплекс готовых к использованию моделей, объединенных единой предметной областью, информационной базой и языком общения с пользователями. МЦ, так же как ПОИС, предназначены для обеспечения проведения исследований на различных моделях. Но, в отличие от ПОИС, они не обеспечивают автоматизацию создания имитационных моделей, а предоставляют пользователю возможность комфортной работы с готовыми моделями. МЦ могут являться системами как коллективного, так и индивидуального использования и в принципе не требуют для своей реализации мощных ЭВМ.
  • Автоматизированные системы обучения (АСО). Традиционные методы обучения специалистов в различных областях профессиональной деятельности складывались многими десятилетиями, в течение которых накоплен большой опыт.

Однако, как свидетельствуют многочисленные исследования, традиционные методы обучения обладают рядом недостатков. К таким недостаткам следует отнести пассивный характер устного изложения, трудность организации активной работы студентов, невозможность учета в полной мере индивидуальных особенностей отдельных обучаемых и т. д. Одним из возможных путей преодоления этих трудностей является создание АСО — автоматизированных информационных систем, предназначенных для автоматизации подготовки специалистов с участием или без участия преподавателя и обеспечивающих обучение, подготовку учебных курсов, управление процессом обучения и оценку его результатов. Основными видами АСО являются автоматизированные системы программного обучения (АСПО), системы обеспечения деловых игр (АСОДИ), тренажеры и тренажерные комплексы (ТиТК). Автоматизированные системы программного обучения ориентированы на обучение в основном по теоретическим разделам курсов и дисциплин. В рамках АСПО реализуются заранее подготовленные квалифицированными преподавателями “компьютерные курсы”. При этом учебный материал разделяется на порции (дозы) и для каждой порции материала указывается возможная реакция обучаемого. В зависимости от действий обучаемого и его ответов на поставленные вопросы АСПО формирует очередную дозу представляемой информации. Наибольшую сложность при создании АСПО составляет разработка “компьютерного курса” для конкретной дисциплины. Именно поэтому в настоящее время наибольшее распространение получили “компьютерные курсы” по традиционным, отработанным в методическом плане дисциплинам (физике, элементарной математике, программированию и т. д.). Автоматизированная система обеспечения деловых игр предназначена для подготовки и проведения деловых игр, сущность которых заключается в имитации принятия должностными лицами индивидуальных и групповых решений в различных проблемных ситуациях путем игры по заданным правилам. В ходе деловой игры на АСОДИ возлагаются следующие задачи:

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

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

  • автоматизированные архивы (АА);
  • автоматизированные системы делопроизводства (АСД);
  • автоматизированные справочники (АС) и картотеки (АК);
  • автоматизированные системы ведения электронных карт местности (АСВЭКМ) и др.

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

Безымянный_3

Рис. Структура программного обеспечения ЭВМ.

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

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

Режимы работы ЭВМ.

Основными режимами являются:

  1. непосредственного доступа,
  2. однопрограммной пакетной обработки,
  3. мультипрограммной пакетной обработки,
  4. коллективного доступа,
  5. клиент-сервер.

Классификация информационных и расчетных задач.

Все задачи, входящие в СППО, можно классифицировать по нескольким признакам:

  • характеру переработки информации;
  • назначению;
  • уровню применения.

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

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

Основы проектирования элементов ПО ИС в экономике.
верх

Основные требования к информационным, расчетным задачам и их комплексам.

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

  • достоверность результатов использования ИРЗ и К;
  • оперативность получения результатов;
  • соответствие ИРЗ и К уровню руководства;
  • системный подход к созданию и применению СПО;
  • обеспечение безопасности обрабатываемой информации.

Достоверность результатов.

Под достоверностью результатов использования ИРЗ (расчета, моделирования) будем понимать соответствие значений параметров, получаемых в результате решения задачи, их требуемым (“истинным”) значениям. Возможными причинами недостоверности получаемых в процессе расчетов результатов являются:

  • неадекватность применяемой математической модели операции (процесса, явления);
  • низкая точность вычислений;
  • ошибки в алгоритме переработки информации, в соот-ветствии с которым работает задача;
  • ошибки пользователя при проведении расчетов;
  • ошибки (сбои) в работе ЭВМ.

Под адекватностью в теории систем понимается степень соответствия используемой математической модели реальному процессу (системе, объекту). Следовательно, для оценки адекватности математической модели необходимо провести реальную операцию, осуществить математическое моделирование этой же операции в тех же условиях и сравнить реальные результаты операции с результатами моделирования, используя некоторый показатель, например, показатель эффективности операции. Если результаты реальной операции будут хорошо согласовываться с результатами моделирования, то это означает, что используемая математическая модель в данных условиях проведения операции является адекватной реальному процессу (системе, объекту). Важно отметить, что в этом случае можно количественно оценить адекватность модели в рамках суждений типа “результаты моделирования расходятся с реальными не более чем на 10%”. Формально оценить адекватность модели не всегда удается, поскольку не всегда возможно проведение реальной операции для сравнения с результатами моделирования (например, для моделей операций, предусматривающих применение ядерного оружия, или крупномасштабных экономических моделей). В таких условиях под адекватностью принято понимать степень доверия должностного лица к результатам моделирования, используемым для принятия решений. При этом невозможно ввести показатель, объективно характеризующий степень адекватности модели. Модель может быть или адекватной, или неадекватной. Должностное лицо должно сделать вывод об адекватности модели на основании анализа существа модели и полноты учета в модели всех факторов, влияющих на проведение операции в конкретных условиях. Низкая точность вычислений также может стать причиной недостоверности получаемых результатов расчета. Существуют две возможные причины возникновения ошибок вычислений: методические ошибки и ошибки округления. Методические ошибки связаны с использованием приближенных численных методов (например, при использовании метода численного интегрирования или дифференцирования функций). Ошибки округлений связаны с тем, что числа в ЭВМ представляются всегда с некоторой точностью, определяемой количеством значащих цифр в записи числа (для современных ЭВМ такие ошибки практически всегда связаны с неверными действиями пользователей, в частности — при программной реализации ИРЗ).

Ошибки в алгоритме переработки информации, в соответствии с которым работает ЭВМ, являются достаточно редким источником недостоверности результатов расчетов и, как правило, бывают связаны с неучетом в алгоритме задачи всех возможных вариантов исходных данных. При некоторых вариантах исходных данных могут возникнуть ситуации, когда алгоритм задачи работает с ошибками. Поэтому при создании алгоритма задачи необходимо тщательно проанализировать возможные значения исходных данных и определить их допустимые значения. Выявление ошибок в алгоритме переработки информации является одной из важнейших целей при проведении контрольных расчетов на этапе приемки ИРЗ. Ошибки пользователя при проведении расчетов являются, на первый взгляд, ошибками, которые невозможно исключить за счет создания специальных алгоритмических и программных средств. Тем не менее существуют способы уменьшения возможностей для появления таких ошибок (конечно, имеются в виду непреднамеренные, “случайные” ошибки). Речь идет о программном контроле вводимой пользователем информации. Эта информация может включать значения параметров или команды. Как правило, при вводе параметров можно программно проконтролировать допустимость значения вводимого параметра, причем ограничения на значения параметра могут быть как постоянными, так и изменяться в зависимости от значений других параметров. Например, в задаче планирования транспортной операции по доставке потребителям какой-либо продукции допустимые значения скорости движения зависят от типов транспортных средств, участвующих в операции, и состояния дорог на маршрутах движения. Что касается контроля команд, вводимых пользователем, то он может включать проверку допустимости данной команды на конкретном этапе работы с задачей (например, проверка наличия всех необходимых исходных данных перед выполнением команды начала расчета), а также выдачу на экран монитора запроса для подтверждения пользователем намерения выполнить какую-либо важную команду (например, при уничтожении каких-либо данных на экран монитора выводится вопрос типа: “Вы действительно хотите уничтожить эти данные?”, и требуется утвердительный ответ пользователя для выполнения команды). Кроме того, особо ответственные команды могут предусматривать запрос на подтверждение полномочий на их проведение (например, ввод пароля).

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

Оперативность результатов.

Под оперативностью получения результатов расчетов на ИРЗ понимается возможность практического использования результатов их решения (расчетов, моделирования) либо в реальном ритме работы, либо за заданное время. Задача обладает требуемой оперативностью решения, если время работы пользователя с ней обеспечивает своевременное применение получаемых результатов в профессиональной деятельности. Время работы с задачей включает время на настройку (при необходимости) программного обеспечения (а иногда и технических средств), подготовку исходных данных, ввод их в ЭВМ, проведение расчетов и выдачу результатов в виде, удобном для дальнейшего использования. Таким образом, оперативность получения результатов расчетов является интегральной характеристикой, которая включает в себя не только скорость вычислений по алгоритму задачи, но и скорость ввода исходных данных, а также получение результатов в виде, не требующем какой-либо дополнительной обработки (переписывания, перепечатывания и т. д.). Поэтому при создании ИРЗ необходимо предусматривать минимально необходимый объем исходных данных, вводимый пользователем при использовании задачи, а также удобство их ввода.

Соответствие уровню руководства

Под требованием соответствия ИРЗ и К уровню руководства понимается:

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

Системный подход

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

Обеспечение безопасности информации

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

Принципы разработки информационных, расчетных задач и их комплексов.

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

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

Централизованность разработки.

Принцип централизованной разработки по единому плану и замыслу на общих информационных и математических основах используется при создании ИРЗ и К в рамках единой АСУ. Этот принцип должен неукоснительно соблюдаться при создании задач, результаты решения которых используются во всех или нескольких звеньях АСУ (например, задач, используемых для автоматизации управления отраслью экономики в министерстве). Для обеспечения централизованной разработки ИРЗ в вышестоящих организациях формируется и утверждается перспективный план создания элементов СПО. В перспективном плане указываются: название ИРЗ, ее заказчик и разработчик, а также срок создания задачи. Перспективный план, как правило, разрабатывается сроком на пять лет. На основании перспективных планов разрабатываются годовые планы создания ИРЗ. Принцип централизованной разработки ИРЗ может не учитываться организациями и фирмами, создающими одноуровневые задачи, предназначенные для применения в рамках данной организации и использующих автономные ЭВМ (например, персональные ЭВМ, не входящие в АСУ). При этом организации выступают в роли заказчика специального математического и программного обеспечения и осуществляют разработку (совершенствование) ИРЗ на основании своих перспективных планов. Отметим, что с насыщением органов управления современной ЭВТ следовать этому принципу становится все труднее и на первое место при его реализации выдвигаются организационные мероприятия.

Конкретность предназначения

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

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

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

Возможность перестройки

Принцип обеспечения возможности перестройки задач в процессе их эксплуатации применительно к конкретной обстановке предполагает, что при создании ИРЗ необходимо более полно учесть возможные изменения обстановки, внешних условий, а также изменения характеристик и условий применения создаваемой продукции, которые вызовут необходимость корректировки алгоритмов и программ ИРЗ. Конечно, заранее предусмотреть и оговорить какие-либо конкретные изменения (кроме плановых — например, модернизации продукции или договорных ограничений) невозможно. Тем не менее при разработке задач необходимо учитывать возможные направления изменения тех или иных параметров, и создавать такие задачи, которые позволили бы с минимумом затрат проводить их корректировку.

Непрерывное сопровождение СПО заказчиком и разработчиком

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

Порядок внедрения информационных, расчетных задач и их комплексов

Прием в эксплуатацию разработанных ИРЗ и К осуществляется по приказу или директиве заказчика. Этим приказом заказчик назначает комиссию по приемке готового программного продукта, определяет ее состав и задачи, а также сроки и порядок ее работы. В задачи комиссии входит:

  • изучить документацию по задаче (комплексу задач), представленную разработчиком, определить ее качество, соответствие требованиям ТЗ и другим нормативным документам;
  • установить соответствие алгоритмов и программ требованиям ТЗ и оперативной постановке задачи;
  • проверить достаточность мер по обеспечению безо-пасности обработки информации и ее выдачи на,автоматизированные рабочие места должностных лиц;
  • провести контрольные расчеты на внедряемой задаче с целью проверки: работоспособности программ, достоверности, полноты и качества получаемых результатов в широком диапазоне исходных данных; практической пригодности и эффективности использования задачи в деятельности командира и штаба по управлению войсками; технологичности, трудоемкости и временных характеристик основных этапов подготовки и ввода исходных данных, проведения расчетов и выдачи результатов;
  • подготовить предложения о внесении изменений в методику работы должностных лиц с использованием результатов применения задачи;
  • при необходимости определить перечень работ и продолжительность этапа опытной эксплуатации задачи (комплекса), а также составить план-задание на ее проведение.

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

  1. не позднее чем за два месяца до начала работы комиссии представить заказчику и организациям, определенным заказчиком, по одному экземпляру документации в согласованном с заказчиком объеме;
  2. представить эталонные программы с контрольными вариантами решений на машинных носителях в ВЦ, на котором планируется внедрение задачи (комплекса);
  3. выполнить контрольные расчеты по указанию заказчика и принять участие в анализе полученных результатов;
  4. устранить недостатки, выявленные в процессе приемки задачи (комплекса).

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

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

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

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

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

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

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

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

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

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

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

Информационное обследование профессиональной деятельности.
верх

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

Объекты автоматизации в системе организаций.

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

Управленческая деятельность может быть представлена как совокупность определенным образом связанных задач управления. Количество, сложность задач управления, решаемых в процессе управленческой деятельности, а также требования по оперативности их решения могут быть различными в различных условиях обстановки. Однако перечень и содержание задач управления, как правило, являются стабильными — неизменяемыми или слабо изменяемыми — в процессе жизнедеятельности организации на достаточно большом интервале времени. Результатами решения задачи управления являются управляющие воздействия на подчиненных и предоставление требуемой информации вышестоящим органам управления, которые оформляются в виде документов (приказов, директив, распоряжений, а также донесений, отчетов и справок). Задачи управления решаются должностными лицами органов управления и так же, как управленческая деятельность, представляют собой процесс переработки информации. Анализ процесса переработки информации при решении какой-либо задачи управления позволяет выделить в нем три типа взаимосвязанных информационных процедур, заключа-ющихся в реализации того или иного механизма переработки входной информации в конкретный результат и индивидуально выполняемых должностными лицами.

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

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

  1. Управленческая деятельность органов управления и должностных лиц.
  2. Задачи управления персоналом, решаемые руководством фирмы в целом или должностными лицами (должностным лицом) в процессе управленческой деятельности.
  3. Полностью и плохо формализуемые информационные процедуры, индивидуально выполняемые должностными лицами (возможно, с использованием различных технических устройств) при решении различных задач управления.

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

Характеристика подходов к автоматизации управленческой деятельности

Информационное обследование, как правило, проводится в ситуации, когда существуют какие-либо недостатки в процессе управления (например, плохое качество управления или плохая оперативность принятия решений), и руководство хочет определить возможность устранения этих недостатков за счет использования средств автоматизации управления. Решать эту задачу необходимо путем анализа процесса управления с целью выделения в нем возможных объектов автоматизации, определения информационных связей между ними и установления необходимого уровня автоматизации информационной деятельности, способного обеспечить решение возникшей проблемы. В такой постановке задача автоматизации управления ставилась и решалась в нашей стране и за рубежом с начала 70-х гг. XX в., причем в качестве объекта автоматизации выбиралась, как правило, управленческая деятельность какого- либо органа (органов) управления. Именно с этого времени стали появляться проекты “больших” АСУ, таких как АСУ предприятия, АСУ отрасли и т. п. Анализ практики создания АСУ позволяет выделить сло-жившиеся и используемые в настоящее время подходы к проектированию систем автоматизации управления.

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

Попыткой устранения недостатков, присущих первому подходу к автоматизации организационного управления, явилась разработка второго подхода, базирующегося на принципе построения АСУ “от модели”, т. е. по принципу “делать так, как должно быть”. Такие АСУ будем называть модельными. Согласно этому принципу проводится анализ объекта управления, а также существующей системы управления и строится модель деятельности новой системы управления, способной решить возникшие проблемы управления объектом. Таким образом, при этом подходе предполагается автоматизировать управление с одновременным изменением (при необходимости) существующей структуры системы управления, а также целей и задач управления. Построение модельных АСУ несомненно улучшает качество управления, однако создание адекватной модели деятельности оптимальной системы управления сложным объектом на начальном этапе автоматизации в большинстве случаев является практически неразрешимой задачей. Практика показала, что в лучших разработках создание АСУ осуществлялось на основе третьего подхода — многошагового, основанного на принципе “от потребностей практики”. Согласно этому принципу на начальном этапе автоматизируется деятельность конкретных должностных лиц последовательно, начиная с автоматизации простейших информационных процедур путем разработки отдельных И и РЗ. Созданные И и РЗ по мере их накопления, оценки эффективности их использования и корректировки объединяются в АИС, автоматизирующие решение задач управления и управленческой деятельности в целом. При такой автоматизации управленческой деятельности уточнение целей и задач управления, а также изменение состава и структуры системы управления происходит постепенно, а автоматизация выполнения информационных процедур проходит всестороннюю проверку еще в процессе создания АСУ. Кроме того, должностные лица постепенно обучаются работе с ЭВМ, и в их сознании укрепляется уверенность в необходимости использования ЭВМ в практической работе. Все сказанное выше обеспечивает успех автоматизации управленческой деятельности. Принцип создания АСУ “от потребностей практики” базируется на трех основных (отчасти противоречивых) требованиях, предъявляемых к процессу создания средств автоматизации управленческой деятельности:

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

Каждый из перечисленных выше подходов может быть применен при создании конкретной АСУ. Если цели и задачи системы управления точно определены и управленческая деятельность хорошо формализуется, целесообразно строить АСУ по принципу “от фотографии”. Если есть возможность разработать модель оптимальной системы управления, целесообразно строить АСУ по принципу “от модели”. Если автоматизация управления находится на начальном этапе, в любом случае целесообразно создавать АСУ в соответствии с принципом “от потребностей практики”, и, по мере накопления И и РЗ, автоматизирующих отдельные информационные процедуры, приступать к созданию фотографических или модельных АСУ.

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

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

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

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

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

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

Информационные модели объектов автоматизации

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

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

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

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

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

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

Оперативная постановка информационной задачи.
верх

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

Оперативная постановка математической модели

Оперативная постановка математической модели должна отражать восемь типовых вопросов.

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

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

  6. Вербальная модель операции.
  7. Вербальная модель операции представляет собой вербальное (словесное) описание моделируемой операции и разрабатывается в основном усилиями представителей заказчика. Она необходима разработчику для создания математической модели операции. В вербальной модели должны быть описаны существо моделируемой операции и ее основные особенности. Для обеспечения полноты описания моделируемой операции вербальная модель включает следующие элементы.

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

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

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

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

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

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

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

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

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

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

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

  12. Варианты работы модели определяются в соответствии с ее местом, ролью и целевой направленностью (см. п.п. 2 и 3 оперативной постановки). По существу в данном пункте должен быть описан сценарий применения модели при решении различных задач управления. Для каждого варианта работы модели должно быть указано допустимое время моделирования.
  13. Если предполагается наличие нескольких вариантов работы модели, должно быть указано допустимое время моделирования для каждого варианта.

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

Особенности оперативных постановок информационных, вычислительных задач и их комплексов.

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

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

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

  1. Название ИЗ.
  2. Место и роль задачи в процессе управления сотрудниками фирмы.
  3. Состав, формы представления, а также порядок ввода и вывода информации на различные технические устройства (дисплеи, печатающие устройства и т. д.).
  4. Состав, структура информации, необходимой для работы задачи, с указанием источников получения этой информации. В данном пункте указываются БД или результаты работы других ИЗ, которые должны использоваться в ИЗ. Если создаваемая ИЗ использует для своей работы информацию, поступающую по каналам связи, необходимо указать состав и структуру этой информации.
  5. Режимы работы и допустимое время работы ИЗ в каждом режиме.
  6. Требования по обеспечению достоверности и защите входной и выходной информации.

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

  1. Название ВЗ.
  2. Место и роль ВЗ в процессе управления персоналом предприятия.
  3. Состав, формы представления, а также порядок ввода и вывода информации на различные технические устройства.
  4. Состав, структура информации, необходимой для работы задачи, с указанием источников получения этой информации.
  5. Перечень приказов, директив и других нормативных документов (или сведений из них), которыми должен руководствоваться разработчик при создании ВЗ. В некоторых случаях может быть непосредственно приведен алгоритм переработки информации, который должен быть реализован в ВЗ.
  6. Режимы работы и допустимое время работы ВЗ в каждом режиме.
  7. Требования по обеспечению достоверности и защите входной и выходной информации.

Создаваемые ИРЗ как элементы специального прикладного программного обеспечения АИС ВН объединяются в комплексы. Оперативная постановка такого комплекса задач должна отражать четыре вопроса.

  1. Название комплекса задач.
  2. Место и роль комплекса задач в процессе управления персоналом и в АИС.
  3. Перечень ИРЗ, входящих в комплекс, и структура информационных связей между ними.
  4. Меры по обеспечению информационной совместимости между задачами комплекса и другими комплексами.

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

Оперативное описание информационных и расчетных задач

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

  • структура И или РЗ — блоки, из которых состоит задача, а также связи между ними;
  • определение шагов моделирования или расчета (под шагом моделирования или расчета понимается часть процесса работы задачи, на которой вычисляются промежуточные результаты);
  • гриф секретности задачи (при необходимости может отдельно указываться гриф секретности программы, исходных данных и результатов счета);
  • условные знаки и символы, используемые при вводе и выводе информации;
  • типы устройств, используемых при вводе и выводе информации и т. д.

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

ПО коммерческого назначения: ERP-, CRM- и SCM-системы.
верх

Система управления взаимоотношениями с клиентами (CRM, CRM-система, сокращение от англ. Customer Relationship Management) — прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами), в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путём сохранения информации о клиентах и истории взаимоотношений с ними, установления и улучшения бизнес-процессов и последующего анализа результатов. CRM — модель взаимодействия, основанная на постулате, что центром всей философии бизнеса является клиент, а главными направлениями деятельности компании являются меры по обеспечению эффективного маркетинга, продаж и обслуживания клиентов. Поддержка этих бизнес-целей включает сбор, хранение и анализ информации о потребителях, поставщиках, партнёрах, а также о внутренних процессах компании. Функции для поддержки этих бизнес-целей включают продажи, маркетинг, поддержку потребителей. CRM-система может включать:

  1. фронтальную часть, обеспечивающую обслуживание клиентов на точках продаж с автономной, распределенной или централизованной обработкой информации;
  2. операционную часть, обеспечивающую авторизацию операций и оперативную отчётность;
  3. хранилище данных;
  4. аналитическую подсистему;
  5. распределенную систему поддержки продаж: реплики данных на точках продаж или смарт-карты.

Основные принципы

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

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

Цели внедрения CRM.

Основной целью внедрения, как правило, ставится увеличение степени удовлетворённости клиентов за счёт анализа накопленной информации о клиентском поведении, регулирования тарифной политики, настройки инструментов маркетинга. Благодаря применению автоматизированной централизованной обработки данных появляется возможность эффективно и с минимальным участием сотрудников учитывать индивидуальные потребности заказчиков, а за счёт оперативности обработки — осуществлять раннее выявление рисков и потенциальных возможностей. В торговой сфере за счёт CRM обеспечивается более эффективное применение метода перекрёстных продаж (англ. cross-selling) и техники апсейла.

Классификации CRM-систем.

  1. Классификация по назначению:
    • Управление продажами (SFA — англ. Sales Force Automation)
    • Управление маркетингом
    • Управление клиентским обслуживанием и колл-центрами (системы по обработке обращений абонентов, фиксация и дальнейшая работа с обращениями клиентов)
  2. Классификация по уровню обработки информации
    • Операционный CRM — регистрация и оперативный доступ к первичной информации по событиям, компаниям, проектам, контактам.
    • Аналитический CRM — отчётность и анализ информации в различных разрезах (воронка продаж, анализ результатов маркетинговых мероприятий, анализ эффективности продаж в разрезе продуктов, сегментов клиентов, регионов и другие возможные варианты).
    • Коллаборативный CRM (англ. collaboration — сотрудничество; совместные, согласованные действия) — уровень организации тесного взаимодействия с конечными потребителями, клиентами, вплоть до влияния клиента на внутренние процессы компании (опросы, для изменения качеств продукта или порядка обслуживания, веб-страницы для отслеживания клиентами состояния заказа, уведомление по SMS о событиях, связанных с заказом или лицевым счётом, возможность для клиента самостоятельно выбрать и заказать в режиме реального времени продукты и услуги, а также другие интерактивные возможности).

Для чего нужны CRM-системы?

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

  1. Не потерять потенциального клиента, не пропустить ни одного входящего звонка и запроса. В малом и среднем бизнесе в нашей стране конкуренция очень высокая. Компании прилагают значительные усилия для того, чтобы привлечь клиентов, чтобы на них обратили внимание. По сравнению с другими затратами на привлечение клиентов выделяется значительный бюджет. И очень важно, чтобы все эти средства и усилия не пропали даром. Автоматизированные системы позволяют получить уверенность, что именно так и будет работать отдел продаж. Вы получите фиксацию каждого входящего звонка, каждого запроса, каждого лида.
  2. Контроль работы сотрудников и стандартизация работы с клиентами. Без общей стандартизированной CRM-системы каждый сотрудник работает так, как он привык. Кто-то ведет учет в электронных таблицах, кто-то – в записной книжке или ежедневнике, кто-то не ведет учет вообще, ориентируется исключительно на отчеты из 1С или на собственную память. Контакты также происходят достаточно хаотично. Письма клиентам могут отправляться как с корпоративного, так и с личного почтового ящика, звонки совершаться с любого удобного телефона, контроль качества работы невозможен. CRM-система почти полностью решает эту проблему. Информация обо всех входящих и исходящих контактах будет находиться в одном хранилище, откуда ее можно в любой момент извлечь.
  3. Накапливается статистическая база, что также очень важно для успешного развития любого бизнеса. Благодаря использованию CRM-системы вся рабочая информация собирается в одной общей базе в стандартизированном виде. В результате руководитель может анализировать статистику работы, составлять различные отчеты (многие из которых уже в готовом виде присутствуют в CRM-системах), т.е. анализировать работу и планировать последующую работу более осознанно.
  4. Готовые решения, от которых можно отталкиваться в построении собственной системы работы. Каждая CRM-система – это воплощение видения разработчиков того, как нужно работать с клиентом. В ней заложено множество готовых инструментов, которые позволяют перевести работу на качественно новый уровень. Например, интеграция CRM-системы с телефонией позволяет фиксировать все звонки, запоминать все новые контакты и анализировать качество работы отдела продаж с лидами. В малом и среднем бизнесе работу с клиентами направляет чаще всего непосредственно руководитель (владелец) бизнеса. У него нет экспертов, а часто нет и наработок по организации работы с клиентами. Руководителю не на что опираться в этом вопросе, а потому и отдел продаж часто работает далеко не лучшим образом. Внедрение CRM-системы позволяет получить не только инструмент, но и помощь, взгляд разработчиков на то, как должен работать отдел продаж. В свою очередь при разработке CRM-системы обычно опираются на лучшие практики, на экспертов в вопросах работы с клиентами. А потому если вы будете активно использовать предоставляемые CRM-системой инструменты, то и работа вашего отдела продаж также будет оптимизироваться. Различные инструменты системы сами подсказывают, какие шаги стоит сделать в процессе оптимизации работы с клиентами.

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

Как выбирать CRM-систему?

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

Saas или Stand-Alone – облака или собственный сервер?

Существует два типа CRM-систем, созданных на основе разных технологий:

  1. Saas или система как сервис. При этом варианте все программное обеспечение и данные находится на сервере поставщика услуг. Вы получаете online- доступ к системе через браузер, программу-клиент или мобильное приложение. Все процессы происходят на стороне поставщика услуг.
  2. Standalone — лицензия на установку и использование программного продукта. Вы получаете решение, которое устанавливаете на собственный сервер, при желании, дорабатываете под свои потребности, в зависимости от тех возможностей, которые предоставляет поставщик CRM-системы.

При выборе Saas-решения вас ждут некоторые ограничения. Вы не сможете ничего изменить в коде продукта, так как программные решения расположены на стороне поставщика CRM-системы. Обычно такие CRM-системы позволяют вам настроить права доступа сотрудников, интегрировать какие-то внешние системы (получать данные с сайта, фиксировать входящие звонки и т.д.), изменить оформление при помощи конструктора, настроить отчеты и т.д. Но все это будет храниться на серверах поставщика CRM-системы. Также важно понимать, что при использовании Saas-решений у вас всегда должен быть доступ к Интернету. Конечно, в наше время надежный Интернет стал давно уже важной частью любого бизнеса, при отсутствии доступа к сети останавливаются многие бизнес-процессы. А потому оптимальное решение – это иметь помимо надежного основного также резервный канал доступа в Интернет. Еще один важный момент, который нужно понимать при выборе Saas-решений: вероятнее всего, за каждое создание резервной копии базы данных и другие подобные операции вам понадобиться платить отдельно. Например, в системе, которую активно использую я, резервное копирование стоит 10 долларов за 1 бэкап. Плюсы Saas-решений:

  1. Вам не нужен собственный сервер для размещения программного обеспечения;
  2. Не потребуется самостоятельно заниматься обновлениями, все это лежит на поставщике услуги, вы просто пользуетесь решением.
  3. О CRM-системе как Saas-решении можно говорить очень много. Возможно, я напишу об этом отдельную статью. Для выбора типа решения достаточно описанных выше особенностей.

Stand-Alone решения, как я уже сказал выше, – это покупка «коробочного» решения, которое вы установите на собственный сервер и сможете менять программный код (в рамках доступа, который предоставил разработчик). В некоторых случаях, например, когда возникает необходимость внедрить нетипичные решения, такой уровень доступа очень важен. Но чаще всего, для среднего и малого бизнеса Stand-Alone решения не требуются. Необходимость в глубоких изменениях возникает крайне редко, а потому я рекомендую обычно Saas.

Интеграция с телефонией.

Я считаю, что любая CRM-система должна интегрироваться с телефонией. Если вы не сможете фиксировать входящие звонки и инициировать исходящие, то это большой минус. А потому при выборе программного продукта для своих клиентов я всегда особо обращаю внимание на наличие этой возможности, а также на то, как она реализована. Казалось бы, можно данные о звонках вносить в систему вручную. Но практика показывает, что этот метод не работает. Люди начинают сопротивляться, их раздражает необходимость выполнять дополнительную работу. Кроме того, любой человек может просто забыть внести в систему тот или иной важный звонок. А потому такой метод на практике обычно не работает. Итак, фиксировать звонки в системе необходимо. Существует 2 варианта реализации:

  1. Звонок делается из самого браузера, он проходит полностью через систему, все взаимодействие происходит через браузер. Важно понимать, что через систему проходит весь звонок, а потому от браузера и кода CRM зависит качество звука, скорость обработки сигнала и т.д.
  2. Телефония интегрируется со сторонними сервисами – asterisk, avaya и др. В этом случае вы устанавливаете систему виртуальной телефонии на базе этих сервисов и подключаете свои номера к этой телефонии. При этом делать все исходящие звонки и получать входящие вы сможете через сип-трубки, а не через браузер. Как это происходит? Ваш сип-провайдер принимает звонок от клиента, перенаправляет его в вашу систему виртуальной АТС, а она уже передает информацию о звонке в CRM-программу. При этом в базе CRM фиксируется номер телефона, время, продолжительность звонка и т.д. Пользователю остается только добавить к записи о звонке свои заметки (краткую тему разговора, результат, комментарии).

Конечно, есть еще вариант фиксирования информации о звонках вручную, но я уже выше описал, почему это не будет работать на практике. Основные рутинные операции должны быть автоматизированы, иначе система не будет работать. API интеграция: наличие готовых решений. Любой бизнес пользуется различными сервисами для получения заявок, ведения учета, оформления документов и пр. При выборе CRM-системы стоит обратить внимание, имеются ли API решения для интеграции с вашим сайтом, обмена данными с 1С, IT-телефонией, другими необходимыми вам программами и сервисами. Наличие готовой API интеграции – это большой плюс. Взаимодействие с контактом (клиентом) обычно складывается из нескольких вещей:

  1. Телефонные звонки;
  2. Email-переписка;
  3. Рассылки (смс или email);
  4. Встречи.

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

Планирование и работа с задачами.

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

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

Как таковой интеграции с смс сервисом я не видел, например, готового решения для интеграции с определенными сервисами смс-рассылок. Это делается в рамках бизнес-процессов или в рамках работы с API. Соответственно, в системе должна быть возможность массовой смс рассылки для всех клиентов, для определенной группы контактов или лично определенному контакту (например, уведомление об определенных действиях).

Импорт данных.

Внимательно рассмотрите, какие возможности предоставляет CRM-система для импорта данных. В каком формате возможна загрузка информации? Существует ли готовый модуль миграции из других систем, и, если да, то из каких? Или надо готовить информацию для загрузки в каком-то определенном формате? Вы должны понимать, каким образом будет осуществляться первичное заполнение данных при запуске системы. Этот процесс в чем-то похож на ввод остатков в систему, о котором я писал в статье. Очень важно, чтобы импорт данных происходил быстро, просто и прозрачно. Без удобного автоматического переноса всех контактов и других важных для работы сведений, запуск системы, скорей всего, окончится неудачей. Конечно, можно вносить все данные вручную, но это очень долго и неудобно. А если вносить эти данные по частям, то повышается риск дублирования карточек клиента, в итоге вас ожидает путаница и накладки. Лично мне очень нравится вариант переноса данных из таблицы Excel, этот вариант универсальный, достаточно наглядный и удобный. В Excel возможна выгрузка практически из любой системы, в том числе, из 1С. А загружать данные в этом формате в систему также достаточно быстро и удобно.

Наличие локализации.

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

Лицензирование: Open Source или проприетарная архитектура?

Разница между Open Source и проприетарной архитектурой заключается в том, что в первом случае вы получаете систему с открытым кодом, а во втором – с закрытым. Понятно, что здесь речь идет о вариантах лицензирования программных продуктов Stand-Alone, так как любая Saas-система по умолчанию имеет закрытый код. Проприетарную (закрытую) архитектуру продают преимущественно крупные разработчики. В этом случае вы получаете мощную систему, в которую вы сможете вносить изменения в пределах, обозначенных разработчиком. Я лично не вижу здесь ничего плохого, ведь, как я уже писал выше, для среднего и малого бизнеса крайне редко вообще требуются какие-то нетиповые решения. Лицензией Open Source (открытый код) отличаются разработки, созданные преимущественно на основе какой-то CMS. В этом случае вы получаете крайне широкие возможности для интеграции и работы с сайтом или другой системой. С другой стороны, такие CRM-модули во многом проигрывают большим CRM-системам, специально разработанным для учета взаимоотношений с клиентами.

Контакты и контрагенты.

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

Стоимость системы.

Любой бизнесмен, прежде чем внедрить то или иное программное решение, задается вопросом, а сколько это будет стоить? При определении цены CRM нужно понимать, что цифры, которые вы видите на сайтах в разделе «стоимость продукта» или «стоимость лицензии» — это только часть общих затрат. А потому стоит разобраться, из чего складывается полная стоимость внедрения CRM-системы. Полная стоимость продукта состоит из несколько частей:

  1. Стоимость лицензии (приобретения). Это может быть оплата доступа для «облачных решений» или стоимость 1 копии.
  2. Перенос данных в систему. Вам обязательно понадобится каким-то образом перенести контакты и другие данные. А потому наличие или отсутствие готового модуля, а также сложность подготовительной подготовки данных для импорта также повлияет на итоговую стоимость.
  3. Стоимость доработки. Даже если вы купили «коробочное решение» или доступ к saas-версии, какие-то доработки все равно потребуются. Нужно будет настроить права доступа, отчеты, задачи и пр.
  4. Стоимость сопровождения.

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

Стоимость лицензии.

В зависимости от типа выбранной вами CRM-системы, возможны различные варианты покупки лицензии. Вы можете:

  1. Купить бессрочную лицензию.
  2. Купить лицензию (подписку) на определенный срок (месяц, год и т.д.)
  3. Купить копию программы для установки на собственный сервер.
  4. Бессрочная лицензия приобретается один раз и действует на постоянной основе. Это удобно, но сумма, которую нужно выплатить сразу, обычно довольно значительная.

Подписка подразумевает покупку доступа к системе на определенный срок. Стоимость подписки обычно невелика, но вам придется регулярно совершать платежи для продления доступа к CRM-системе. При сравнении стоимости лицензий нужно учитывать также и маркетинговые ходы, к которым часто прибегают продавцы. Так, очень часто продавцы CRM-систем на сайте рекламируют минимальную цену пакета услуг, которая будет действовать только при определенных условиях. А в реальности вам придется за эту систему платить больше. Например: на странице с описанием пакета услуг указана цена 40 долларов за 1 пользователя в месяц. Но если внимательно прочитать весь текст, в том числе, выноски и примечания, оказывается, что эта цена действительна только в случае покупки не менее 10 лицензий одновременно сроком на 1 год. А если вам требуется всего 9 лицензий, цена уже будет другой. Подобные маркетинговые хитрости очень характерны для рынка IT. Но подробно о хитростях лицензирования я планирую поговорить в отдельной статье. А сейчас достаточно просто запомнить, что нужно внимательно относиться к условиям формирования цены, чтобы не обмануться в своих расчетах. В случае покупки программы вы оплачиваете один раз неограниченное количество лицензий. Вам не понадобится оплачивать доступ к программе ни периодически, ни в случае расширения штата сотрудников. Но любые обновления для вашей программы будут платными.

Доработки и запуск системы как часть ее стоимости.

Работы по настройке, доработке и запуску программного обеспечения также нужно учитывать при расчете общей стоимости CRM-системы. Вам потребуется:

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

Очень часто пользователи при расчете затрат забывают учесть перенос данных, что является серьезной ошибкой. Перенос данных – это одна из самых больших затрат при запуске системы. Данные нужно извлечь из существующей системы, обработать, стандартизировать, исправить в них ошибки, и только потом эти данные можно будет загружать в CRM-систему. Например, я обычно предлагаю своим клиентам такую услугу, как исправление телефона. Это очень распространенная проблема: в карточках контрагентов 1С, в таблицах Excel и во многих других программах телефоны клиентов можно записывать произвольным образом. В итоге, часть записей оказывается в формате «+7….», часть начинаются с восьмерки, часть – городские номера вообще без кода города и т.д. Для того, чтобы эти телефоны корректно были внесены в CRM-систему, они должны быть стандартизированы, приведены в определенный вид (чаще всего в международный формат). Также важно понимать, что доработки вам потребуются в любом случае. Даже если вы приобретаете полностью готовое коробочное решение, вам все равно, скорей всего, потребуется что-либо дорабатывать. Лучше заранее ориентироваться на то, что вам понадобится оплачивать также и в этом вопросе услуги специалиста.

Что дорабатывать, если выбрано Saas-решение?

С одной стороны, при использовании Saas-решения у вас нет доступа к коду, а потому и дорабатывать силами программиста нечего. С другой стороны, Saas-платформы дают достаточно широкие возможности настройки различных форм и отчетов, бизнес процессов, прав пользователей, внешнего вида вашей рабочей системы и пр. Эту работу также стоит доверить специалисту. Кроме того, вам потребуется интеграция вашей CRM-системы с сайтом, программами 1С, телефонией и т.д. Эту работу также выполняет специалист, а потому ее стоимость нужно учитывать. Standalone решения требуют дополнительных вложений: покупка или аренда сервера, его настройка, покупка дополнительного программного обеспечения и т.д. Важно понимать, что при покупке Standalone-решения вы покупаете просто копию программы. А все дальнейшие расходы, связанные с ее установкой, настройкой, ее использованием, вы берете на себя.

Сопровождение.

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

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

Напомню, что для малого и среднего бизнеса я обычно рекомендую именно Saas-решения для внедрения CRM-систем. И экономия на внедрении и сопровождении является при этом далеко не последним фактором. ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности. ERP-система — конкретный программный пакет, реализующий стратегию ERP. Концепция ERP сформулирована в 1990 году аналитиком Gartner как видение развития методик MRP II и CIM (англ.), в начале — середине 1990-х годов появилось несколько успешных тиражируемых ERP-систем для крупных организаций, наиболее известные — разработки компаний Baan (нидерл.), Oracle, PeopleSoft, SAP, JD Edwards, сформировался рынок услуг по внедрению ERP-систем с участием компаний большой четвёрки, в 2000-е годы произошла консолидация поставщиков, появилось значительное количество ERP-систем для малого и среднего бизнеса, наиболее известными поставщиками которых стали Sage Group и Microsoft. Внедрение ERP-системы считается фактически необходимым условием для публичной компании и, начиная с конца 1990-х годов, ERP-системы, изначально внедрявшиеся только промышленными предприятиями, эксплуатируются большинством крупных организаций вне зависимости от страны, формы собственности, отрасли. Понятие ERP ввёл аналитик Gartner Ли Уайли (англ. Lee Wylie) в 1990 году в исследовании о развитии MRP II. Уайли спрогнозировал появление тиражируемых многопользовательских систем, обеспечивающих сбалансированное управление всеми ресурсами организации, не только относящихся к основной деятельности производственного предприятия, но и объединяющих посредством общей модели данных данные о производстве, закупках, сбыте, финансах, кадрах. В начале 1990-х годов концепция обрела известность за счёт поддержки производителями прикладного программного обеспечения, в частности, она была реализована в продукте SAP R/3, выпущенном в 1992 году в развитие пакета управления материальными потоками SAP R/2 (нем.) для мейнфреймов и Oracle Applications, созданном в эти годы на основе интеграции и реинжиниринга приложений, разработанных корпорацией Oracle на заказ в конце 1980-х годов. К середине 1990-х годов сформировался рынок консультационных услуг по внедрению ERP-систем, причём внедрением систем занимались не только сами производители программного обеспечения, но и консалтинговые компании. Так, в 1996 году в Andersen Consulting было 3200 консультантов по внедрению R/3, в самой SAP — 2800, в PricewaterhouseCoopers — 1800, в Deloitte & Touche — 1400, а в 1999 году из 50 тыс. R/3-консультантов в SAP работало только 10 %.

В 1998 году PricewaterhouseCoopers, характеризуя рынок ERP-систем, ввела в общеупотребительный оборот акроним BOPSE — Baan (нидерл.), Oracle, Peoplesoft, SAP, JD Edwards — обозначающий пятёрку основных поставщиков ERP. Кроме этих систем на рынке конца 1990-х годов отмечались как существенные игроки также (non-BOPSE) Lawson, Great Plains, QAD, Ross and Solomon. Также отмечено, что по состоянию на 1998 год более 60 % транснациональных корпораций внедрили SAP R/3. Если в начале 1990-х годов ERP-системы внедрялись, прежде всего, в промышленности, и, как решения реализующие MRP II как компонент — машиностроительными предприятиями, то во второй половине 1990-х годов применение ERP-систем стало повсеместным и в сфере услуг, в том числе предприятиями электросвязи, энергосбытовыми компаниями, и даже органами государственной власти и некоммерческими организациями. К этому же времени в связи с быстрым ростом количества модулей в ERP-системах и их функциональных возможностей относится представление о ERP-системах как всеобъемлющем программном обеспечении для организаций, принципиально заменяющем все прочие прикладные программы, сменившееся к началу 2000-х годов выделением таких функций как CRM и PLM в отдельные от ERP программные пакеты и очерчиванием рамок ERP как универсальных систем для бэк-офисных процессов и управления ресурсами (а CRM-систем — рамками внешних взаимоотношений и фронт-офиса, и PLM — интеллектуальной собственностью). С ростом популярности всемирной паутины и развитием функциональных возможностей веб-браузеров в конце 1990-х — начале 2000-х годов, практически все ведущие производители оборудовали ERP-системы веб-доступом (первые попытки реализации отдельных функциональных возможностей для браузера относятся к 1996 году в SAP, но первой, реализовавшей всеобъемлющий веб-доступ к системе, была Oracle в 1998 году, SAP реализовала полный веб-доступ в 1999 году, веб-интерфейс для Peoplesoft появился в 2000 году). К 1999 году относится начало разработки первой свободно распространяемой ERP-системы — Compiere, впоследствии появились и другие свободные ERP-пакеты, самые известные из них — ADempiere, Openbravo (форки Compiere), ERP5, OpenERP. В первой половине 2000-х годов произошла существенная консолидация поставщиков ERP-систем: в 2000-м году Microsoft поглотила Great Plains (на основе её продуктов сформирован пакет Microsoft Dynamics GP), и объединённую компанию Damgaard и Navision (сформировав соответственно пакеты Microsoft Dynamics AX и Microsoft Dynamics NAV), в 2003 году Peoplesoft приобретает JD Edwards за $1,7 млрд, выйдя на второе место на рынке ERP с долей 12 % (при общем объёме рынка $23,6 млрд в 2004 году), опережая Oracle и уступая только SAP, а в 2004 году Oracle осуществил враждебное поглощение PeopleSoft за $10,3 млрд. К 2006 году объём проданных лицензий на ERP-системы составил $28 млрд, увеличившись по сравнению с 2005 годом на 18 %, доли поставщиков распределились следующим образом: SAP — 42 %, Oracle — 25 %, Sage Group — 7 %, Microsoft — 7 %, Infor — 6 %, к 2010 году отрыв SAP и Oracle сократился до 24 % и 18 %, а доля Microsoft — выросла до 11 %. Вторая половина 2000-х годов отмечена повсеместным оснащением ERP-систем поддержкой сервис-ориентированной архитектуры: для большинства ведущих систем была обеспечена возможность вызвать любую функцию автоматизированно стандартизованным способом. Благодаря этому обеспечено снижение издержек на межсистемную интеграцию в организациях, использующих системы от разных производителей, появились платформы и готовые реализации композитных приложений (фр. Application composite).

Начиная с середины 2000-х годов возникла целая серия ERP-систем, предоставляющихся исключительно по подписке (наиболее известные из них — NetSuite и Plex), а с ростом популярности облачных вычислений и основные поставщики обеспечили предоставление заказчикам своих систем по подписке. В качестве характеристической особенности ERP-стратегии отмечается принципиальный подход к использованию единой транзакционной системы для подавляющего большинства операций и бизнес-процессов организации, вне зависимости от функциональной и территориальной разобщённости мест их возникновения и прохождения, обязательность сведе́ния всех операций в единую базу для последующей обработки и получения в реальном времени сбалансированных планов. Тиражируемость, то есть возможность применить один и тот же программный пакет для разных организаций (возможно, с разными настройками и расширениями), фигурирует как одно из обязательных условий ERP-системы. Одной из причин повсеместного использования тиражируемых ERP-систем вместо разработки на заказ указывается возможность внедрения лучших практик посредством реинжиниринга бизнес-процессов согласно решениям, применённым в ERP-системе. Однако, встречаются и упоминания интегрированных систем, разработанных для отдельной организации на заказ как ERP-систем. Необходимость всеобъемлющего применения ERP-системы в территориально-распределённых организациях требует поддержки в единой системе множества валют и языков. Более того, необходимость поддерживать несколько организационных единиц (несколько юридических лиц, несколько предприятий), несколько различных планов счетов, учётных политик, различных схем налогообложения в едином экземпляре системы оказывается необходимым условием для применения в холдингах, транснациональных корпорациях. Применимость в различных отраслях накладывает на ERP-системы, с одной стороны, требования к универсальности, с другой стороны — поддержку расширяемости отраслевой спецификой. Основные крупные системы включают готовые специализированные модули и расширения для различных отраслей (известны специализированные решения в рамках ERP-систем для машиностроительных и обрабатывающих производств, предприятий добывающей промышленности, розничной торговли, дистрибуции, банков, финансовых организаций и страховых компаний, предприятий электросвязи, энергетики, организаций сектора государственного управления, сферы образования, медицины и других отраслей). Модульный принцип организации позволяет внедрять ERP-системы поэтапно, последовательно переводя в эксплуатацию один или несколько функциональных модулей, а также выбирать только те из них, которые актуальны для организации. Кроме того, модульность ERP-систем позволяет строить решения на основе нескольких ERP-систем, выбирая из каждой лучшие в своём классе модули (англ. best-of-breed). Разбивка по модулям и их группировка различная, но у большинства основных поставщиков выделяются группы модулей: финансы, персонал, операции. В 1990-е годы в качестве модулей крупных ERP-систем поставлялись решения для клиентского обслуживания, управления проектами и управления жизненным циклом продукции, но с бурным развитием самостоятельных решений классов CRM, PPM (англ. Project portfolio management) и PLM соответственно, эти модули были либо перепроектированы как отдельно поставляемые продукты, и, фактически, сохраняя преемственность в рамках пакетов бизнес-приложений, просто перестали позиционироваться как часть ERP-продукта, либо были заменены в продуктовых линейках на отдельные, специализированно разработанные решения.

Финансы.

Финансовые модули, прежде всего, главная книга, многими практиками считаются центральными компонентами ERP-системы, а формирование финансовой отчётности средствами ERP-системы считается одним из фактически обязательных условий для положительных результатов due diligence. Среди финансовых модулей ERP фигурирует множество различных функциональных блоков, в разных системах и разных версиях выделяются различные их компоновки, среди наиболее часто встречающихся (по организационным подразделениям):

  1. бухгалтерские: главная книга, счета к получению (дебиторы), счета к оплате (кредиторы), консолидация;
  2. учётно-управленческие, контроллинговые: учёт затрат и доходов по местам возникновения, по продуктам, по проектам, калькуляция себестоимости;
  3. казначейские: управление ликвидностью, управление движением денежных средств (включая банковские счета и кассу), взаимодействие с банками, управление долгом и заимствованиями;
  4. финансово-управленческие: управление основными средствами, инвестиционный менеджмент, финансовый контроль и управление рисками.

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

Персонал.

Одним из принципиальных отличий ERP как стратегии от использования раздельных приложений для MRP II и автоматизации расчёта зарплаты было представление о тесной интеграции информации о трудовых ресурсах для возможности оперативного планирования и управления операциями с учётом информации о доступности персонала, возможности точно рассчитывать затраты по местам возникновения и продуктам в согласовании с информацией о компенсации задействованного персонала. Примечательно, что один из лидирующих поставщиков ERP конца 1990-х — начала 2000-х годов — Peoplesoft — начинал свою деятельность именно как разработчик пакетов для кадрового учёта и расчёта зарплаты. В начале 2000-х годов ведущие поставщики продвигали представление о необходимости управления персоналом как человеческим капиталом организации (соответственно, введя в употребление аббревиатуру HCM, англ. human capital management), и в рамках реализации этой концепции нарастили функциональные возможности модулей управления персоналом в части возможности ведения информации о профессиональных навыках, планирования обучения, карьеры сотрудников и обеспечив применимость информации, обрабатываемой в этих модулях, для целей стратегического управления организацией, расчёта ключевых показателей эффективности, финансового менеджмента. Среди модулей управления персоналом в ERP-системах 2000-х годов: кадровый учёт, учёт рабочего времени (табельный учёт), управление нарядами на работы, командировками, расчёт производительности трудовых ресурсов, управление оплатой труда, премиями, компенсациями и расчёт заработной платы, пенсионный учёт, оценка персонала, управление квалификацией (профессиональными навыками, обучением), подбор персонала.

Операции.

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

  • Логистические: снабжение, управление взаимоотношениями с поставщиками, управление цепочками поставок и транспортировкой, управление запасами, складами, инвентаризацией;
  • Производственные: управление спецификациями (англ. Bill of materials) (в дискретных производствах) и рецептурами (в процессных производствах (англ. Process manufacturing)), производственное планирование, учёт продукции, управление производственными программами;
  • Обеспечивающие: управление техническим обслуживанием и ремонтами оборудования, планирование мощностей, управление транспортом;
  • Сбытовые: ценообразование, обработка и конфигурирование заказов, продажи, дистрибуция, послепродажное обслуживание.

Отдельные функции операционного блока зачастую выносятся в специализированные программные продукты и фигурируют как выделенные классы прикладного программного обеспечения, таковыми являются EAM для технического обслуживания и ремонтов, CRM для продаж и дистрибуции, PLM для управления спецификациями, APS и MES для управления производством.



Заметили опечатку?

Выделите текст и нажмите CTRL+ENTER.

Поступить в МИЛ

  • captcha

Поступить в МФЭИ

  • captcha

Demo Demo