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

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

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте.

Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3].

Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

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

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

Наличие всевозможных методологий по управлению проектами внедрения ERP-систем может запутать новичка [1-3]. Ведь проекты внедрения могут вестись согласно каскадной однопроходной модели или многопроходным, к которым относят итерационную и спиралевидные модели [4]. В первом случае говорят о применении PMBoK [1], во втором Agile направленных подходов [2], к примеру: Scrum, Kanban и др. Несмотря на информационный хайп и сложность внедрения корпоративных систем в подавляющем большинстве применяются каскадные способы имплементации. Поэтому понимание сути и особенностей применения PMBoK становится критичным.

Свод знаний по управлению проектами (PMBoK) дает базис понимания того, как управлять любым проектом, в том числе в области ИТ. Поэтому содержательная часть заполняется активностями и задачами, специфичными для корпоративных информационных систем [5]. Достаточно часто руководителями проектов внедрения информационных систем являются выходцы из функциональных консультантов. Последнее не исключает и обратную ситуацию, когда проектный менеджер есть лицо далекое от ERP-систем. Проходя через множество проектов имплементации, консультант обретает те необходимые знания, которые позволяют понять структуру и организацию проекта, однако дефициты в понимании проектного управления все равно могут остаться.

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

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

Корпоративные информационные системы позволяют автоматизировать набор бизнес-процессов. Чем больше процессов, тем представительнее стандарт, цифровизирующий их. Так наиболее известным и востребованным классом систем является ERP [2]. ERP-системы охватывают практические все административно-хозяйственные операции компании и представляют средства для их автоматизации. Помимо ERP доступен широкий набор прочих классов: MRP, TMS, WMS, APS, BI, MES и др. Если раньше идея объединить все стандарты в единый класс казалась обоснованной, то на текущий момент – это утопия, так как слишком стремительно развиваются технологии и появляются новые виды систем.

Потребность в управлении различными классами программных систем, являющихся основой функционирования современного предприятия, становится все более востребованной и незаменимой: достижение стратегических целей компании тесно связано с вопросом цифровизации бизнес-процессов. Среди множества сводов знаний, применимых к информационным системам: PMBoK, BABoK, BPM CBoK, DAMA-DMBoK, EABoK/TOGAF, SWEBoK, ITIL [3-9], последние два являются наиболее релевантными тематике данной статьи. Свод знаний по программной инженерии, SWEBoK, охватывает весь жизненный цикл информационной системы, в то время как лучшие практики по управлению ИТ-услугами, заданные в ITIL, не ограничиваются рассмотрением только софтверных решений, а представляют все многообразие ИТ-продуктов.

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

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

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

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

Внедренный программный продукт подлежит дальнейшему развитию, причин для которого достаточно: изменение законодательства, технологические тренды и новинки, цифровизация не автоматизированных областей и др. Часто подобные активности над ИТ‑системами связывают с запросами на изменение (ЗНИ), относящимися к процессу управления изменениями. Это действительно так, однако работа с ЗНИ требует выстраивания регулярных бизнес‑процессов, вовлекающих как бизнес‑пользователей, так и технических специалистов, обеспечивающих надзор над корпоративной архитектурой предприятия и соблюдение целостности существующих ИТ‑сервисов. Для чего согласно EABoK [4] организуются следующие организационные сущности:

Жизненный цикл программного обеспечения включает в себя множество этапов. Так в работе [1] выделяют активности по предпроектному обследованию, внедрению программного обеспечения и непосредственно пост-проекту имплементации. Этап поддержки и развития относится к пост-проекту внедрения и призван обеспечить непрерывное функционирование разработанной и запущенной в продуктивный режим работы программной системы. По большому счету, это именно тот результат, который изначально ожидается от реализации любого программного продукта: его постоянное и качественное функционирование для удовлетворения нужд пользователей и достижения стратегических целей предприятия.

Существует множество различных сводов знаний, применимых к комплексным программным системам: PMBoK для управления проектами, BABoK для бизнес-анализа, BPM CBOK для управления бизнес-процессам, EABoK для управления кооперативной архитектурой, а также SWEBoK по программной инженерии. Практически во всех сводах знаний делается акцент именно на внедрение и смежные активности, забывая про то, что имплементация программного продукта завершается его передачей в поддержку. Одним из немногих литературных источников по данной тематике является ITIL [2], описывающий четыре домена знаний, позволяющих осуществлять сопровождение решения после его реализации.

В контексте BABoK и расчета бизнес-кейса, выполняемого при предпроектном обследовании, довольно часто рассчитывается показатель TCO (Total Cost of Ownership, совокупная стоимость владения), демонстрирующий постоянные и переменные затраты, которые понесет компания при внедрении программного обеспечения. Одной из постоянных статей затрат является сумма поддержки и развития информационной системы. Таким образом, знание особенностей выполнения этапа поддержки и развития программной системы позволяет рационально планировать затраты и разумно ограничивать содержание проекта имплементации.

Несмотря на упоминание различных способов разработки программных систем, существует три классические модели, применимые в том числе для внедрения коробочных программных решений [1]:

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

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

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

Стратегия является ключевым документом, описывающим предполагаемый подход к решению той или иной задачи. В области внедрения ERP-систем выделяют такие концепции доставки содержания, как: анализа, проектирование, реализация, ролей и полномочий, миграции, обучения, тестирования, технической подготовки системы, бизнес-катовера, изменений и поддержки. Основой использования стратегий в проектах имплементации ERP-систем служит теория корпоративных информационных систем, предложенная в работе [1]. Анализ литературных источников в области корпоративных информационных систем и стратегий доставки включает множество работ [2-14], однако в них лишь косвенно указана первопричина формирования концепции, что, следовательно, делает выбор того или иного способа недоказательным.

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

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

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

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

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

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

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

Внедрения ERP‑систем практически всегда рассматриваются как высокорискованные проекты. Основная причина здесь в больших временных и человеческих затратах: обычно проект имплементации длится около 1-го года, трудозатраты внедрения только на стороне подрядчика рассчитываются от 1000 человеко‑дней. Грамотное и своевременное планирование и исполнение задач в подобных условиях является залогом успеха. Имплементация ERP‑систем преимущественно ведется по каскадной однопроходной модели внедрения [1], где часто используются принципы Agile [2]. Руководство же проектом обычно базируется на PMBoK [3]. Однако и этого бывает недостаточно, так в литературных источниках описывают типовые причины провала проектов имплементации корпоративных систем [4].

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

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

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

Создание проектного плана может вестись согласно двум классическим способам, описанным в своде знаний PMBoK [2]: критический путь и критическая цепь. Метод критического пути предполагает декомпозицию всех проектных задач, выстраивание их логической последовательности и взаимосвязей, выставление предполагаемых продолжительностей и расчет одноименного пути. Способ не оперирует человеческими ресурсами, поэтому не всегда понятно на основе каких правил рассчитываются продолжительности задач, ведь они зависят от числа ресурсов. Следующий способ, метод критического пути, расширяет предыдущий, вводя три вида «буферов» (ресурсные, поддерживающие и проектные), для сглаживания неопределенностей и возможных задержек. Здесь сроки задач и наличие буферов устанавливаются согласно доступности человеческих ресурсов, после чего строится все тот же критический путь. Применение обоих методов на практике видится крайне трудозатратным в особенности при часто изменяющихся вводных. Поэтому в качестве базиса построения ресурсного плана воспользуемся методом, основанном на бенчмаркинге фаз ERP-проекта [3].

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

Последовавший в начале 2022 года уход из России практически всех известных вендоров от Microsoft, до SAP и Oracle, показал нашу сильную зависимость от прививаемого годами зарубежного ИТ-сервиса. По существу, начало полноценного замещения зарубежного ПО началось именно с этого момента, когда российские компании поставили перед фактом остановки поддержки, продления лицензий и работы самого ИТ-решения. Большинство ИТ-менеджером и директоров судорожно стало думать о переходе на российские аналоги, в частности на продукты 1С, как базового корпоративного решения. Однако, использование нового ПО на предприятии возможно лишь после его имплементирования, процесс которого оказался также сильно завязан на страны запада.

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

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

В Советском Союзе в 1948 г. проблемы развития вычислительной техники становятся общегосударственной задачей. Были развернуты работы по созданию серийных электронно-вычислительных машин ЭВМ первого поколения (термин ЭВМ вместо «компьютер» употреблялся вплоть до конца 1980-х гг.).

Первыми изобретателями компьютера в СССР являются И.С. Брук и Б.И. Рамеев, совместно разработавшие проект цифровой ЭВМ с жестким программным управлением. В декабре 1948 г. они получили авторское свидетельство на изобретение «Автоматической цифровой машины».

«МЭСМ» (малая электронная счетная машина) – первый компьютер в СССР и в целом в континентальной Европе, была создан в 1951 г. под руководством С.А. Лебедева. Под его же руководством в дальнейшем были разработаны и сконструированы машины серии «М» (М-1, М-2 и другие ее модификации), из которых М-20 в 1960-х гг. была признана в СССР лучшей из отечественных машин. Специализированные ЭВМ, созданные под руководством С.А. Лебедева для системы противоракетной обороны, стали основой достижения стратегического паритета между СССР и США во время холодной войны.

В 1950 г. в Институте точной механики и вычислительной техники (ИТМ и ВТ) был организован отдел цифровых ЭВМ для их разработки и создания. В 1951 г. там была спроектирована машина БЭСМ (большая электронная счетная машина), а уже в 1952 г. началась ее опытная эксплуатация.

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

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

Информационные системы (ИС), являясь составляющей частью информационной инфраструктуры, представляет собой систему обработки информации совместно с соответствующими организационными ресурсами (человеческими, техническими, финансовыми и др.), обеспечивая ее распространение (ISO/IEC 2382:2015). ИС предназначена для своевременного обеспечения людей надлежащей информацией, то есть для удовлетворения конкретных информационных потребностей в рамках определённой предметной области, при этом результатом функционирования информационных систем является информационная продукция: документы, массивы данных, базы данных и информационные услуги. По охвату задач информационные системы можно классифицировать на персональные, групповые, корпоративные, системы органов власти и государственных учреждений [1].

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