Вахлов Михаил Григорьевич

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

Цель:
По роду своей деятельности системного аналитика предприятия Франчайзи 1С сталкивался с различными аспектами разработки (доработки) процессов бухгалтерского учета и бюджетировния. Выработалась общая схема подходов к созданию автоматизированной системы (АС), которая в свою очередь также может быть описана  в одной из технологий описания бизнес процессов, а именно SADT (Structured Analysis & Design Technique).
Описание предназначено прежде всего для руководителей проектов и руководителей предприятий разработчиков АС, уже знакомых с технологией SADT. Возможно, это поможет упорядочить общие представления об управлении процессами при разработке АС.
Данная схема применима для создания любой АС, но для конкретности  выбрана АС управления бухгалтерским учетом и бюджетированием/

Оглавление:

1. Общая схема управления процессами

2. Работа с клиентами

3. Обследование

4. Концептуальное проектирование

5. Написание технического задания

6. Программирование

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

8. Выводы

1. Общая схема управления процессами

Основные принципы технологии SADT(не вдаваясь в общую суть теории):
1. Моделирование происходит от самых общих процессов к детализированным процессам иерархически
2. Любой процесс строго описывается схемой:

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

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

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

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

Мне кажется что первоначальный процесс условно названный «Работа с клиентом» должен проходить до заключения договора так как еще до договора необходимо понять принципиальную возможность производства работ требования к АС заказчика  и много другое и основные моменты принципы должны быть отражены в договоре, документе, имеющем юридическую силу при дальнейших разбирательствах. Так как АС не может быть принципиально описано до конца строго разбирательства в том числе и судебные все чаще имеют место). На мой взгляд, в договоре должны быть описаны ресурсные рамки Обследования, Написания ТЗ и Сопровождения. Необходимо оговорить и привлекаемые ресурсы  каждой стороны.
Обследование не может вестись просто так. Оно должно вестись с конкретной точки зрения (со стороны заказчика), учитывая требования и пожелания. Это помогает. Также помогает наличие директивных документов и должностных регламентов, которые часто бывают довольно запутанными. Но главным при обследовании является эксперт предметной области (ЭПО). Чаще это начальник подразделения. От его опыта и знаний, от правильно построенной беседы зависит многое, если не все. В моей практике был случай, когда я дважды обследовал одно и то же подразделение. Первый раз беседовал с молодым человеком , заместителем начальника. Второй раз с начальником (во время первой беседы он был в отпуске), старым зубром. Получилось 2 совершенно непохожие диаграммы, причем вторая намного проще и понятнее. Результатом обследования должно стать некое формализованное описание. (формализация дает возможность всем – заказчикам, руководителям проекта, разработчикам, программистам, говорить и документировать на одном языке. Для этой цели, на мой взгляд, идеально подходят диаграммы IDEF0, DFD и IDEF3. Но на изучение единого формализованного языка, конечно, потребуется силы, время и добрая воля и желания каждого участника проекта. О полезности знания языков рассуждать не приходится. Диаграммы должны утверждаться ЭПО и ответственным за этот проект со стороны заказчика (того, чья фамилия стоит на главной диаграмме как «точка зрения».
Комплекс диаграмм является основой для проектирования  концептуальной модели. Без нее трудно приступить к программированию и написанию технического задания (ТЗ).
Написание ТЗ наиболее ответственный процесс, так как тоже является юридическим документом, подписываемым сторонами. Возможно, нужен более подробный проект системы. Но, как правило, такой проект тесно переплетается с ТЗ и что-то одно надо выбрасывать.
В вопросы блока программирования мне бы не хотелось погружаться – много зависит от системы программирования, стандартов, принятых в фирме разработчика, нет до сих пор по большому счету стандартов тестирования и Engineering Insurance. Но, безусловно, необходимо заставить программистов читать с листа processing diagrams, отвечать за созданные программные куски,  отвечать за соответствие программы концептуальной модели и утвержденным диаграммам,  выдавать предложения на изменения концептуальной модели и далее предложений на дообследование, быть членами команды, а  не «вещью в себе» как это зачастую бывает. Ну и документацию конечно тоже надо заставить писать программистов, как бы это не было противно их высокоинтеллектуальной  программисткой душе. Как мы уже все наелись листингом без комментариев и документацией на программу, читая которую больше всего хочется узнать к какой программе она написана.
Совершенно уникальный блок процессов Сопровождение. Как будет установлена АС, как отлажена, как будет обучен персонал, так и будет завершен проект. На этом этапе затемняются все недостатки и выпячиваются все достоинства. Оперативное взаимодействие с программистами может помочь решить многие проблемы, хотя некоторые из них грозят затянутся в мертвый узел.

2. Работа с клиентами

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

 

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

3. Обследование

Обследование целиком проводят системные аналитика (сотрудники отдела системного анализа)
Кстати о системных аналитиках. Возможно, их правильнее называть аналитиками бизнес процессов, так как они никаких других методов кроме анализа бизнес процессов не занимаются, а собственно системный анализ более широкое понятие. Но отдел лучше называть отделом системного анализа так как на уровне отдела могут применятся другие виды анализа, например ситуационный анализ (SWOT (СВОТ)-анализ) или другое.
Курирует вопросы обследования начальник отдела проектирования  или руководитель проекта так как обследование проводится, прежде всего, в интересах проектирования АС.
Группа процессов относится к планированию. Как и любой процесс, растянутый по времени (а это может быть от одного до 3 месяцев), Обследование лучше проводит по плану. Отметки в плане дадут возможность руководству хоть какую-то уверенность, что процесс не завис.
Перед обследованием системный аналитик должен быть в курсе предметной области . Если мы ведем речь о системе 1С  значит это ПБУ. Правила бюджетировния, Правила управленческого учета. Насколько  глубоко надо входить в предметную область трудно сказать, но терминологию знать необходимо, иначе разговора с ЭПО, может, просто не получится.

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

4. Концептуальное проектирование

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

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

5. Написание технического задания

 

Одним из важнейшим документов разработки является техническое задание (ТЗ).
Часто ТЗ делается для отписки, так как это заложено в текст договора. Но потом при въедливом заказчике возникает множество неприятностей связанных со стыковкой результатов работ с ТЗ.
ТЗ должно соответствовать ГОСТам 24 и 34 серии. Основополагающим является ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы»  Не смотря на давнишний год введения данный ГОСТ полно и структурировано излагает пункты, на которые следует обратить внимание при проектирование АС.  Требования к содержанию документов, разрабатываемых при создании АС изложены в РД 50 - 34.698 – 90.
Попытка систематизировать требования показана на диаграмме.

 

 

Попытка систематизировать ГОСТ 34.602.89 вылилась в следующую диаграмму

6. Программирование

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

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

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

8. Выводы

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