ФУНКЦИОНАЛЬНОЕ (или процессное) МОДЕЛИРОВАНИЕ ПРЕДПРИЯТИЯ Васильев В.В

ФУНКЦИОНАЛЬНОЕ (или процессное) МОДЕЛИРОВАНИЕ ПРЕДПРИЯТИЯ

Многочисленные реплики коллег системных аналитиков о предвосхищении основных современных стандартов по системам управления (хотя бы ERP-MRP) в SU в 80-х годах прошлого века уже несколько надоели (Россия - родина слонов!). Но не во всех случаях эта тема относится к истории науки. Сохраняется необходимость развития теории прикладного системного анализа, развития систем терминов и определений, создания определенного базиса для углубления общения системных аналитиков
Эти соображения автор хотел бы использовать, как повод почтить память и вспомнить о школе своего учителя Юрия Ивановича Сухотина. Подход, разрабатываемый под его руководством на предприятиях Минавиапрома в 70-80-х годах прошлого века, носил название функционального (на сленге АСУшников - , см. далее) и вызывал много споров. Сейчас он широко известен под именем процессного подхода.
Итак, имеем группу системных аналитиков перед которыми поставлена класси- ческая задача создания КИС: проработка функциональности, подготовка реинжинири- нга, структуризация базы данных, организация и руководство программированием (или настройка ПО) и т.д., и т.п.. Группа уже провела блиц-обследование (без детализации бизнес-операций, материальных, финансовых и информационных потоков).
На ближайшем этапе требуется применить один из методов динамического моделирования предприятия в части формализованного описания бизнес-процессов, выбора объектов автоматизации, уточнения ролей и обязанностей персонала и т.п.. При этом используем подход Ю.И.Сухотина для обоснования состава исследуемых бизнес- процессов, выделив четыре этапа:
декомпозиция целей (анализ системы целей);
анализ процессов, реализующих цели;
декомпозиция процессов управления (построение функционального пространства);
рекомпозиция процессов управления.

ФУНКЦИОНАЛЬНОЕ (или процессное) МОДЕЛИРОВАНИЕ ПРЕДПРИЯТИЯ

Васильев В.В. ОАО ГМК "Норильский никель"

Многочисленные реплики коллег системных аналитиков о предвосхищении основных современных стандартов по системам управления (хотя бы ERP-MRP) в SU в 80-х годах прошлого века уже несколько надоели (Россия - родина слонов!).

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

Эти соображения автор хотел бы использовать, как повод почтить память и вспомнить о школе своего учителя Юрия Ивановича Сухотина. Подход, разрабатываемый под его руководством на предприятиях Минавиапрома в 70-80-х годах прошлого века, носил название функционального (на сленге АСУшников - , см. далее) и вызывал много споров.

Сейчас он широко известен под именем процессного подхода.

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

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

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

АНАЛИЗ СИСТЕМЫ ЦЕЛЕЙ

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

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

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

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

Пусть указанное направление реализуется самостоятельным отделением фирмы, состоящим из:
управления продаж;
управления закупок;
оптовой базы маттехснабжения.

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

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

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

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

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

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

Для данной фирмы достаточно рассмотреть только ее критические: материальные, финансовые, трудовые и информационные ресурсы.

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

АНАЛИЗ ПРОЦЕССОВ

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

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

Символически изобразим их схемой на рис.1.

Отметим постулат: "Каждый процесс всегда является более или менее крупным элементом обобщенного процесса (назовем его жизненным циклом предмета труда), а любой предмет труда на определенной стадии является ресурсом для жизненного цикла другого предмета труда".

Пример укрупненного жизненного цикла условного предмета труда под названием "Механизм" приведен в табл.1.

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

Ю.И.Сухотин выделил наиболее важные по его мнению этапы упомянутого жизненного цикла, касающиеся сферы обращения ресурса, и предложил унифицировать их состав и взаимосвязи в виде т.н. СУПР - связки управляемых процессов (см. рис.2).

Обратим внимание как по форме, сути и применению СУПР напоминает современные категории типовых бизнес-процессов, например, рефмодели системы BaanIV.

Таблица 1 Этапы жизненного цикла "Механизма"
Этап
Форма существования

Выявление возможной потребности в механизме
Ментальная (идея,мысленный образ)

Составление ориентировочного описания механизма для зондирования рынка
Знаковая (текст)

Подготовка сделки
Знаковая (текст)

Заключение контракта (контрактов) на создание (поставку, обслуживание)
Знаковая (текст)

Проектирование механизма
Знаковая (чертеж, текст)

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

Изготовление составляющих частей
Вещественная (заготовки, детали, узлы)

Сборка механизма
Вещественная (механизм в сборе)

Продвижение механизма к заказчику
Вещественная (механизм в сборе)

Запуск механизма
Вещественная (механизм в сборе)

Эксплуатация и обслуживание механизма
Вещественная (механизм в сборе)

Ремонт механизма
Вещественная (механизм в сборе)

Демонтаж и утилизация механизма
Вещественная (лом и отходы)

Архивирование (или уничтожение) документации и данных в БД
Знаковая (чертеж, текст на б/н или м/н)

Как выше отмечено, всегда найдется внешний процесс, для которого данный предмет труда является ресурсом. А коль так, то любую "ресурсную" стрелку на рис.1 можно изобразить в виде СУПР, и все они будут пересекать стрелку реализации главной цели своими элементарными процессами "Использование" (см. рис.2). Но сама эта стрелка также должна раскрываться своей СУПР (к каждому элементарному процессу которой должны подаваться ресурсы), согласно вышеприведенному постулату.

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

Обратим внимание, что в СУПР одновременно присутствуют процессы с предметом труда как информационной, так и материальной природы (форма существования по табл.1). Чтобы уточнить это явление используется тривиальное понятие двузвенника.

Будем считать, что всякая имеющая цель система состоит из двух взаимодействующих частей: объект управления (ОУ) и управляющая часть (УЧ). Здесь под объектом управления будем понимать совокупность управляемых процессов, а под управляющей частью - совокупность процессов управления (это означает, что в понятиях данного подхода говорится не \"шофер управляет автомобилем\", а \"реализуется процесс управления движением автомобиля\").

Мы уже рассмотрели систему целей и возможности декомпозиции главной цели функционирования и знаем, что компонент системы в свою очередь является системой. Тогда, предположив, что любая главная цель дает свой определенный \"срез\" системы (вспомним о необходимости ввода наблюдателя в определение системы), получим иерархию встроенных двузвенников, аналогично рис.3 (что это, как не свойство \"рекурсии\" по Биру?).

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

Какие простые и набившие оскомину утверждения, г-да системные аналитики!

Но всегда ли мы о них вспоминаем?

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

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

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

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

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

нкций управления (точный их перечень в данном контексте - вопрос вторичный, достаточно подробно рассмотренный в монографии Мангутова и Уманского).
С использованием понятий ФУБа и системы встроенных двузвенников вернемся к СУПР.

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

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

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

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

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

ФУНКЦИОНАЛЬНОЕ ПРОСТРАНСТВО

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

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

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

Рассмотрим значения функциональных координат для нашего примера:

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

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

в) предмет - запчасти по контракту;

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

д) дискретность управления: p.м.в., день, месяц, год;

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

K=Q(t)*P/S,
где: Q - количество объектов;
t - временные характеристики существования объектов;
P - показатели качества объектов;
S - стоимость объекта.

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

АГРЕГАЦИЯ

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

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

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

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

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

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

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

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

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

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

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

Получим интересный результат. Как род деятельности - это специфическая функция аппарата управления (не путать с функцией управления, упомянутой ранее) под названием . А как комплекс операций по сбору, обработке и предоставлению информации - одноименный бизнес-процесс.

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

В качестве иллюстрации изложенного, на рис.5 приведена структура бизнес- процессов верхнего уровня агрегации, построенная с применением указанных принципов для МПС.

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

Для другого объекта исследования данный бизнес-процесс имел бы другие составляющие, например (близко к American Productivity & Quality Center по сайту С.Рубцова or-rsv.narod.ru):
анализ рынка и потребностей;
разработка видения и стратегии;
разработка продуктов и услуг;
производство (оказание услуг);
продажа продуктов и услуг.

Выделенные наиболее важные вспомогательные цели дают четыре ресурсных бизнес-процесса:
материально-техническое обеспечение;
финансовые процессы;
использование инфраструктуры;
обеспечение персоналом.

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

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

Высокая степень адаптивности этой модели к многим объектам исследования, с т.з. автора, наводит на мысль о правильности основных положений подхода.

ЗАКЛЮЧЕНИЕ

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

Автор данной статьи ни в коей мере не намерен покушаться на личные методы работы своих коллег и тем более поучать их.

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

В практике автора он так же с успехом использовался при проведении тендеров, создании "коробочных" систем (а ранее - типовых АСУП), стандартизации в области процессов проектирования СУ и т.д..

Другое дело, что можно и надо много спорить по существу многих аспектов метода, изложенного здесь так сжато.

По мнению автора такую дискуссию можно было бы организовать на базе любого постоянного действующего форума системных аналитиков, например, одноименного Клуба фирма РИККОН) или на форуме КИС-CFIN.

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

https://www.lobanov-logist.ru/library/all_articles/54842/

Возврат к списку