CC BY
78
УДК 004.053 В.Е. Кириенко
Исследование вопросов типизации проектных решений в области информатизации управления организациями
Выдвинуты три гипотезы в плане реализации принципа В.М. Глушкова о типовости проектных решений. Определены признаки отнесения приложения к типовым на основе классификации сущностей средств идеализированного проектирования по степени сложности, предложенной Р.Л. Акоффом. На основе гипотез сформулированы выводы, определяющие актуальность типизации в условиях широкого использования облачных технологий.
Ключевые слова: унификация, типизация, проектные решения, информационная система, приложение, модульность.
Унификация (приведение к единой форме или системе), стандартизация (установление правил и характеристик в целях их многократного использования), типизация (обоснованное сведение многообразия типов к небольшому числу) решений (приложений, информационных систем) были и остаются особо острой проблемой автоматизации, а затем, в современной терминологии, информатизации управления. Дискуссии по этим вопросам ведутся от зарождения автоматизированных систем управления (АСУ) и продолжаются до сих пор.
С самого начала автоматизации выдвигалось требование унификации проектных решений. Такой подход нашел свое выражение в одном из принципов создания АСУ, провозглашенных В.М. Глушковым. Это принцип типовости, который заключается в следующем: при разработке ком -понентов АСУ, включая прикладные программы, связанные с ними базы данных и выходные формы, проектировщик обязан стремиться к тому, чтобы предлагаемые им решения могли тиражироваться для большого круга заказчиков. Типизация решений должна способствовать концентрации сил при создании комплексных АСУ [1].
Конечно, на процесс типизации накладывают свои ограничения техническая база, программное обеспечение. Но всё-таки основная причина неудач в этом деле - мультивариантность «организационно-экономической базы» объектов автоматизации (предприятий, организаций, территориальных и отраслевых органов управления). Под базой понимаем совокупность экономических принципов, методов организации и управления, схем взаимодействия задач управления на основе правовых документов. Следовательно, главная причина торможения в реализации принципа типизации - различия в модели объекта каждого отдельно взятого заказчика.
Несмотря на предупреждение В.М. Глушкова о необходимости «разумной степени типизации», в качестве типовых порой объявлялись программные приложения задач АСУ конкретной организации в целом. При данном подходе не учитывалось, что структура функциональной части АСУ во многом зависит от применяемой в определенной организации схемы процедур управления. А она, в свою очередь, является определяющей взаимосвязи всех элементов управления и охватывающей как автоматизированные, так и частично механизированные и ручные процедуры.
В чем же секрет типизации, какие решения могут быть тиражированы и внедрены во многих объектах автоматизации - организациях и их совокупностях, а какие заведомо не подходят под эту категорию? Пожалуй, здесь нужно определиться, что, во-первых, мы будем понимать под типовым приложением, во-вторых, на основе каких признаков мы можем отнести то или иное приложение к тем, которые, по выражению В. М. Глушкова, вполне разумно рассматривать в качестве типовых.
Типовое приложение информационной системы - это то, которое не требует внесения изменений в исходный код программы при её тиражировании, или требуемые изменения кода программы соответствуют наилучшему соотношению между предполагаемыми результатами от использования информационной системы и затраченными ресурсами: временными, человеческими, финансовыми.
При определении признаков, по которым какое-либо приложение может претендовать на отнесение к типовым, обратимся к классификации сущностей средств идеализированного проектирования по степени сложности, предложенной Р.Л. Акоффом.
В соответствии с [2] примем за основу следующие определения:
1. Действие (акт) - одноразовое, обычно кратковременное поведение.
2. Процедура — совокупность одновременных или последовательных действий, направленных на получение результата.
3. Практика - рутинно повторяемая процедура.
4. Процесс - совокупность процедур, образующих сквозное осуществление чего-либо.
5. Проект - система одновременных или поочередных процессов, направленных на получение результата.
6. Программа - система проектов, нацеленных на производство совокупности связанных исходов. Опираясь на эти определения, будем считать, что общий термин, который мы употребляем -
«информационная система» - будет соотноситься с ними следующим образом:
1. Подзадача информационной системы - информационная система, автоматизирующая действие (акт).
2. Задача информационной системы - информационная система, автоматизирующая процедуру.
3. Подсистема информационной системы - информационная система, автоматизирующая процесс.
4. Информационная система - информационная система, автоматизирующая проект.
5. Корпоративная (единая, общая) информационная система - информационная система, автоматизирующая программу.
Обозначим каждое из пяти соотношений как категорию системы и покажем их место в управлении организации, и её информационной системе (рис. 1).
Рис. 1. Категории систем в терминах управления и информации
Проиллюстрируем применение этих представлений на примере автоматизации бухгалтерского учета. Пожалуй, это самая «благодарная» область для машинной обработки данных, чему способствовали её алгоритмичность, арифметические операции, и что сделало её программное приложение первым по очередности и числу повторений со времени начала использования ЭВМ в «гражданских» сферах деятельности человека. Поэтому пример автоматизации бухучета будет прозрачен для многих, если не всех поколений российских разработчиков информационных систем, да и не только российских.
В качестве подзадачи может выступать, например, формирование документов «Платежное поручение», «Счет», «Счет-фактура» и подобных им. Действительно, само по себе создание этих документов с возможностью генерирования самой «платежки», «фактуры» и журналов их учета вполне оформляемо в виде самостоятельной информационной системы. Такие системы в свое время были разработаны автором данной статьи, оформлены в виде «коробочного» продукта и пользовались большим спросом у бухгалтеров многих организаций. За неполные два года было реализовано более 1500 экземпляров программ.
Под задачей информационной системы можно понимать отдельно взятые автоматизированные процедуры кассовых операций («Касса»), банковских операций («Банк»), материального учета («Склад»), расчета заработной платы («Зарплата»), формирования главной книги («Главная книга»), формирования баланса организации («Баланс»).
Совокупность всех указанных автоматизированных задач бухгалтерского учета будет составлять подсистему «Бухгалтерский учет» информационной системы организации.
Информационная система организации содержит, например, вместе с подсистемой «Бухгалтерский учет», такие подсистемы: «Производство», «Кадры», «Плановые расчеты» и т.д.
Представление о корпоративной информационной системе связаны с организациями, имеющими, как правило, большие масштабы, территориально разнесенные и самостоятельные подразделения, филиалы, производящие большую номенклатуру конечных продуктов. К ним в полной мере, можно отнести органы территориального управления. Корпоративные информационные системы содержат на порядок больше информационных систем, в отличие от отдельных организаций. Вот некоторые современные данные: «Авторам известен и такой факт. Служба ИТ одного из крупнейших российских банков поддерживает работу более 300 различных прикладных систем. Наличие нескольких сотен прикладных систем скорее правило, чем исключение для органов власти регионального уровня» [3]. Очевидно, что крупный банк, территориальные органы управления представляют собой по существу корпорации.
Возвращаясь к вопросу о типизации приложений и опираясь на предложенные здесь категории информационных систем, продолжим рассуждения на основе упомянутого ранее закона В.М. Глуш-кова о «втором барьере» информационной сложности управления развитием общества, описываемого экспоненциальной функцией [1]. Функциональная закономерность выведена ученым на основе анализа сложности задач управления, возрастающего с переходом общества на новые ступени развития количественного и качественного состава связей, активного взаимодействия между производителями продуктов и потребителями.
Если следовать рассуждениям В.М. Глушкова, то можно утверждать, что эта же функциональная закономерность будет присуща информационным системам в управлении, так как информатизация - это производная от управления. Сложность информационных систем будет возрастать, во-первых, от информатизации малого предприятия до корпорации, во-вторых, от задачи информационной системы до корпоративной информационной системы соответственно.
Отсюда, мы можем выдвинуть следующие две гипотезы по отношению к принципам В.М. Глушкова о типизации решений и модульности.
Гипотеза о возможности типизации приложений. Чем сложнее категория сущности информационной системы, тем менее она способна стать типовой системой для тиражирования.
Вывод. Как правило, в качестве типовых информационных систем можно рассматривать отдельные подзадачи, задачи и подсистемы информационной системы.
Проиллюстрируем зависимость оценки возможности типизации решений в информатизации организационного управления от категории информационной системы в графическом виде (рис. 2). На оси абсцисс представлены категории информационных систем в порядке возрастания сложности. Так как информатизация - производная от управления, то, согласно закону В.М. Глушкова о «втором барьере» это возрастание сложности будет носить экспоненциальный характер. На оси ординат отображается оценка оценки возможности типизации решений в терминах: «высшая», «высокая», «средняя», «низкая» и «рисковая».
Показать зависимость можно и иным образом: на оси ординат отобразить «простоту» типизации каждой категории систем в количественном виде. Но для этого потребуется определение того, какие характеристики информационной системы будут служить основой для «оцифровки» и как она будет производиться. Как пример количественного подхода можно привести «Типовые нормы времени на программирование задач для ЭВМ» [4]. Основными факторами, которые лежат в основе расчета норм времени, служат «количество макетов (наборов данных) входной информации» и «количество разновидностей форм выходной информации» с учетом различных коэффициентов (сложности, степени новизны и др.).
В указанных типовых нормах есть определяющая часть, где сказано следующее: «Под задачей следует понимать комплекс программ и данных, требующих ресурса машины для своей реализации» и «Под группой задач следует понимать задачи, реализуемые подсистемой управления или учета. Например, учет основных средств или учет материальных ценностей в подсистеме «Бухгал-
терский учет» и т.д. [4]. А под модулем обычно понимают «функционально законченный фрагмент программы как часть её исходного текста». То есть авторы методики подходят к выделению частей информационной системы с точки зрения её программно-аппаратного комплекса. Отличие нашего подхода состоит в том, что формулировки опираются на содержание самой управленческой деятельности.
Теперь обратимся к тому, как можно в настоящее время на основе данного подхода выделять модуль системы на примере муниципальной информатизации. Когда речь идет об административном регламенте выполнения функции или предоставления услуги, то под этим понимается некий процесс, включающий в себя определенный набор процедур. На основе выделенных нами категорий получаем, что автоматизацию административного регламента (процесса) обеспечивает информационная подсистема, а автоматизацию каждой его процедуры - задача. Так как административный регламент должен представлять собой целостную и непротиворечивую систему, то выдвинем такую гипотезу.
Гипотеза о модульности. За основу для выделения в информационной системе организации той её части, которую можно определить как модуль, нужно рассматривать такую категорию, как подсистема информационной системы.
Приведем еще один аргумент в пользу данной гипотезы. Очень часто говорится о несовместимости информационных систем. Несовместимость порождает несоответствие моделей «чужих» подзадач, задач концептуальной модели предметной области «своей» подсистемы в целом. Так как концептуальная модель отображается в структуре базы данных (БД) любой информационной системы, то несогласованность моделей приводит к отсутствию в БД необходимых объектов, сущностей и соответствующих им атрибутов. То есть когда говорится о несовместимости информационных систем, то имеется в виду несогласованность моделей. Если же модели идентичны, то нет никаких препятствий для интеграции, например, приложений, написанных на разных алгоритмических языках. Для этого и существуют такие средства, как XML. Но чужеродные подзадачи и задачи, как правило, не согласованы по моделям, поэтому встраивание их в оригинальные подсистемы практически неосуществимо.
Справедливости ради отметим, что не в любом случае встраивание и на уровне подсистемы возможно. Здесь требует обязательного учета качества систем таких категорий, как информационная система и корпоративная информационная система. Если последние имеют платформенную основу, то это одно, а если они заведомо реализованы в том виде, который исключает развитие, то это другое. То есть сама сущность модульности имеет свои особенности в каждом отдельном случае информатизации управления. Поэтому высказанное предложение о том, что считать модулем, может служить только отправной точкой в анализе и синтезе целостных информационных систем.
Вывод. Гипотеза о модуле дает нам представление о том, что можно понимать под модульностью, выражаемой одним из принципов разработки АСУ В.М. Глушкова.
В подтверждение верности двух рассмотренных гипотез можно привести факт, который был описан в российских публикациях по электронному правительству. В США есть опыт неудачного подхода к разработке e-Govemment. Дело в том, что сначала была сформирована программа работ с масштабными проектами, рассчитанная на длительный горизонт планирования. На определенном этапе был проведен аудит состояния работ, который показал низкую эффективность реализации программы. Тогда сама программа была пересмотрена в сторону постановки менее масштабных проектов с прозрачными конечными продуктами и небольшими сроками их производства. В результате в запланированные сроки и с требуемым качеством она была реализована. То есть категория
Оценка возможности типизации по категориям
Средняя •
Высокая « Высшая ■
Подзадача ^ Подсистема ^ Корпоративная Задача Система система
Рис. 2. Зависимость возможности типизации от категории системы
различных информационных систем от «глобального» продукта переведена во вполне обозримую для проектирования, что способствовало успешной реализации программы е-Ооуетшеп1 в целом.
Открытым остается вопрос о том, какую же информационную систему можно считать типовой. Решению проблемы признания тех или иных информационных технологий в качестве типовых для однородных организаций призвана помочь следующая гипотеза.
Гипотеза о типовости конкретного решения. Для признания информационной системы (решения) типовым необходимо и достаточно того, чтобы она была введена в эксплуатацию не менее чем в 12 организациях.
Гипотеза базируется на исследованиях в области применения методов экспертных оценок в управлении. Есть экспериментальные данные, характеризующие зависимость достоверности экспертизы от количества экспертов. Они говорят о том, что достоверность оценок монотонно возрастает с ростом числа экспертов. Характер возрастания таков, что довольно высокий уровень достоверности оценивания - 0,8 достигается уже при 11-12 экспертах. После этого рост достоверности становится менее ощутимым даже при значительном возрастании количества экспертов. Так как каждый муниципалитет можно представить в качестве независимого эксперта, следовательно, и график (рис. 3), приведенный авторами исследования [5], вполне можно интерпретировать в качестве отражающего степень типовости решения.
Проверка этой гипотезы особо актуальна в условиях действия облачных технологий, но есть еще один аспект, который может вызвать интерес. Можно утверждать, что при определении типовости системы решается и обратная задача: если группа организаций «высказалась» за типо-вость конкретной системы, то она может быть признана обязательной для данного класса организаций. Это, в свою очередь, может отразиться на модели организационноэкономической базы объектов автоматизации, что, в свою очередь, позволит привести, например, к типизации организационной структуры объектов определенного класса.
Литература
1. Глушков В.М. Введение в АСУ. - 2-е изд., испр. и доп . - Киев : Техшка, 1974. - 320 с.
2. Акофф Р.Л. Менеджмент в XXI веке (Преобразование корпорации). - Томск: Изд-во Том. унта, 2006. - 418 с.
3. Данилин А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия / А. Данилин, А. Слюсаренко. - М.: Интернет-ун-т информ. технологий, 2005. - 504 с.
4. Типовые нормы времени на программирование задач для ЭВМ // Бюллетень Госкомтруда СССР - М.: НИИ труда, 1982. - № 10. - 22 с.
5. Евланов Л. Г. Экспертные оценки в управлении / Л. Г. Евланов, В. А. Кутузов. - М.: Экономика, 1978. - 133 с.
Степень типовости решения 1,0 —I
0,8 —
0,6
0,4 —
Количество
организаций
11 13
—I----1---1--1----
13 5 7
Рис. 3. График зависимости типовости решения от числа организаций
Кириенко Владислав Евгеньевич
Канд. техн. наук, доцент каф. АОИ ТУСУРа
Тел.: 8 (383-2) 51-44-25
Эл. почта: vek@admin.tomsk.ru
Kirienko V.E.
The research on type design solutions in the informatization
In this article we point out three hypotheses in terms of implementation the principle of typification by VM. Glushkov. We identify the signs of referring the application to the basic ones by means of the classification of entities of idealized design graded according to the degree of complexity by R.L. Ackoff. On the basis of the hypotheses the conclusions were formulated, they indicate the relevance of typification in the cloud technologies.
Keywords: standardization, typification, design solutions, information systems, application, modularity.
