Данная статья посвящена реинжинирингу бизнес-процессов компании, занимающейся разработкой программного обеспечения.
Ключевые слова: реинжиниринг,бизнес-процесс, контекстная диаграмма, декомпозиция, диаграмма потоков данных, издательство, издательство спортивного журнала, редакционно-издательская деятельность.
В простейшей модели жизненный цикл организации состоит из пяти стадий: внедрение, рост, зрелость, падение и обновление. Наибольшая прибыль соответствует стадии зрелости, поэтому главная задача команды менеджеров организации продлить эту стадию на максимально возможное время. Учитывая постоянно меняющиеся внешние условия, данная задача может быть решена путём проведения реинжиниринга бизнес-процессов. Под реинжинирингом принято понимать фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения максимального эффекта производственно-хозяйственной и финансово-экономической деятельности.
Первым шагом реинжиниринга бизнес-процессов организации является построение модели «Как есть» и определение «узких» мест, которые негативно влияют на деятельность компании в целом. Проанализировав модель бизнес-процессов компании, занимающейся разработкой ПО, представленную в работе [4], можно сделать вывод, что в компании не используются элементы системы менеджмента качества, разработчик непосредственно общается с клиентом, тестирование и приемка работ происходит непосредственно на стороне клиента. Всё это влияет на сроки и качество выполнения работ, о чём говорит низкая оценка деятельности компании.
Целью данной статьи является проведение реинжиниринга компании для увеличения прибыли компании.
Основные изменения должны быть внесены в организацию процесса работы компании уровня А0, а именно он должен быть выстроен по принципу цикла PDCA Эдварда Дёминга. PDCA – циклически повторяющийся процесс принятия решения, используемый в управлении качеством [7].
Методология PDCA представляет собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Цикл управления начинается с планирования. Планирование – установление процессов, необходимых для достижения результата, планирование работ по достижению целей процесса и удовлетворения потребителя, планирование выделения и распределения необходимых ресурсов. Выполнение – выполнение запланированных работ. Проверка – сбор информации и контроль результата на основе ключевых показателей эффективности, получившегося в ходе выполнения процесса, выявление и анализ отклонений, установление причин отклонений. Воздействие (управление, корректировка) – принятие мер по устранению причин отклонений от запланированного результата, изменения в планировании и распределении ресурсов [7].
Для этого на схему АО вносится дополнительный процесс «Анализ результатов работы», связанный со всеми подпроцессами основного бизнеспроцесса «Оказание услуг по веб-разработке» компании.
Для сокращения времени реализации проектов по веб-разработке и повышения управляемости процессом реализации предлагается ввести матричную структуру управления с выделением роли руководителя проекта.
Матричная структура управления – организационная структура управления, основанная на принципе двойного подчинения исполнителей. В случае матричной структуры управления сотрудник предприятия подчиняется руководителю своего отдела и руководителю проекта (временной целевой программы). Что касается руководства, на данном уровне в матричной схеме происходит разделение прав руководителей отделов и проектов. Так, например, первые могут заниматься распределением ответственностей за задачи, а вторые — установкой сроков и содержания работ [3].
Графически матричная структура изображается в виде решетки, или матрицы. Матрица такой системы управления представляет собой пересечение проектной и функциональной структуры, в которой по вертикали строится управление по подразделениям (отделам), а по горизонтали согласно программно-целевой структуре организуется управление проектами.
Целью применения матричной схемы является повышения эффективности взаимодействия подразделений предприятия с целью реализации поставленных задач [3].
Для управления процессом сбора требований к конечному продукту в команде проекта необходимо предусмотреть роль методолога, основной задачей которого должно стать посредничество между клиентом и разработчиком. На этапе «Выполнение работ» в блоке «Сбор и анализ требований» методолог проводит консультации с клиентом с целью сбора и систематизации требований. Затем совместно с разработчиком методолог готовит техническое задание. На данном этапе методолог представляет интересы клиента. Также по результатам разработки на методолога ложится ответственность за тестирование конечного продукта и проверку его соответствия требованиям клиента.
Наличие в команде проекта методолога позволит перейти от «экстремального» программирования к «каскадной» модели программирования. Каскадная модель – модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки [2].
Следуя каскадной модели, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того, как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того, как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка – внесение новой функциональности и устранение ошибок.
Тем самым, каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз - не происходит.
Диаграммы «КАК ДОЛЖНО БЫТЬ» приведены на рисунках 1-5 (все изменения выделены красным цветом).
Рисунок 1 – Функциональная модель оказания услуг по веб-разработке
Рисунок 2 – Детализация бизнес-процесса «Оказание услуг по веб-
разработке»
Рисунок 3 – Подпроцесс «Планирование работ»
Рисунок 4 – Подпроцесс «Выполнение работ»
Рисунок 5 – Подпроцесс «Приемка результата»
Итак, основными задачами реинжиниринга для компании по услугам в области веб-дизайна ООО «Связь-Сервис-Сети» являются:
сокращение сроков реализации проектов;
сокращение возвратов готового продукта на доработку;
повышение качества работы компании.
Решение указанных задач позволит достичь основной цели деятельности компании – увеличение прибыли.
Критерии достижения цели. Критерий достижения целей – количественный показатель, определяющий меру или степень оценки достижения целей по сравнению с другими возможными вариантами [6].
Для постановки целей будем использовать методологию SMART. SMART – это мнемоническая аббревиатура, используемая в менеджменте и проектном управлении для определения целей и постановки задач:
Specific (Конкретность): объясняется, что именно необходимо достичь. Например, «увеличить чистую прибыль собственного предприятия».
Measurable (Измеримость): объясняется, в чем будет измеряться результат. Если показатель количественный, то необходимо выявить единицы измерения, если качественный, то необходимо выявить эталон отношения. Например, «увеличить прибыль собственного предприятия на 25% относительно чистой прибыли текущего года».
Attainable (Достижимость): объясняется, за счет чего планируется достичь цели. И возможно ли ее достигнуть вообще. Например, «увеличить прибыль собственного предприятия на 25% относительно чистой прибыли текущего года за счет снижения себестоимости продукции, автоматизации ресурсоемких операций и сокращения штата занятых на исполнении автоматизируемых операций сотрудников на 80 % от текущего количества».
Relevant (Уместность): определение истинности цели. Действительно ли выполнение данной задачи позволит достичь желаемой цели. Например, если брать «сокращение штата занятых на исполнении автоматизируемых операций сотрудников на 80 %» в качестве отдельной подзадачи, которая также ставится по SMART, то сотрудников можно не увольнять, а перевести на иные должности, на которых эти сотрудники смогут принести компании доход, а не просто экономию.
Time-bound (Ограниченность во времени): Определение временного промежутка, по наступлению / окончанию которого должна быть достигнута цель (выполнена задача). Например, «к окончанию второго квартала следующего года увеличить прибыль собственного предприятия на 25 % относительно чистой прибыли текущего года за счет снижения себестоимости продукции, автоматизации ресурсоемких операций и сокращения штата занятых на исполнении автоматизируемых операций сотрудников на 80% от текущего количества» [1].
Итак, сформулируем цели и критерии их достижения с использованием методологии SMART:
снизить до 20% («Число договоров с нарушением сроков» / «Общее число договоров за период» *100%) количество проектов с нарушением сроков выполнения договоров до конца следующего отчетного периода за счет реинжиниринга бизнес-процессов работы компании;
снизить до 5% («Число договоров с возвратом от клиента на доработку» / «Общее число договоров за период» *100%) количество случаев по возврату клиентом готового решения на доработку до конца следующего отчетного периода за счёт применения механизмов внутреннего тестирования;
увеличить оценку качества работы компании до 8 баллов из 10 (средняя оценка по анкетам обратной связи) до конца следующего отчетного периода за счет применения элементов системы управления качеством.
Основные положения проекта по реинжинирингу. Проект реинжиниринга бизнеса, как правило, включает четыре этапа:
Разработка образа-видения будущей компании. На этом этапе компания строит картину того, как следует развивать бизнес, чтобы достичь стратегических целей.
Анализ существующего бизнеса - проводится исследование компании и составляются схемы ее работы в настоящий момент.
Разработка нового бизнеса - создаются новые и (или) изменяются прежние процессы и поддерживающая их информационная система, тестируются новые процессы.
Внедрение проекта нового бизнеса [5].
Важно то, что перечисленные этапы выполняются не последовательно, а, по крайней мере, частично параллельно, причем некоторые из них повторяются.
Таким образом, в работе [4] был проведён анализ существующих бизнес-процессов. В данной работе представлен проект новых бизнес-процессов, определены цели и критерии их достижения. На завершающем этапе необходимо внедрить новые бизнес-процессы в работу.
Перед проведением реинжиниринга необходимо подготовить персонал. Для этого следует провести общее собрание сотрудников компании, на котором руководитель должен объяснить причины проведения реинжиниринга, его цель, задачи и сроки реализации проекта.
Затем следует внести изменения в локальные нормативные акты, а именно в положения о подразделениях и должностные инструкции сотрудников внести сведения о введении матричной функциональной структуры – разделить зоны влияния руководителя подразделения и руководителя проекта.
В штатное расписание компании необходимо внести должность методолога и осуществить поиск сотрудника, обладающего следующими ключевыми компетенциями: высшее техническое образование, знание предметной области, знание особенностей реализации языков программирования, владения методологиями тестирования программных продуктов.
В качестве «пилотного» необходимо выбрать один из существующих проектов компании средней сложности. Возглавить данный проект необходимо руководителю компании. В ходе реализации проекта должны быть активно использованы средства коллективной работы такие, как Битрикс, Trello. Затем формируется команда проекта и составляется календарно-сетевой график реализации. Составлению графика должно быть уделено особое внимание:
крупные задачи должны быть декомпозированы на более мелкие, ответственность за выполнение конечной задачи должна лежать на одном сотруднике;
сроки выполнения должны быть максимально реальными;
должны быть указаны критерии выполнения каждой задачи, например, отчёт о разработке или тестировании.
Руководитель проекта ежедневно отслеживает состояние реализации проекта и, при необходимости, вносит корректировки.
Работа по реализации проекта по веб-разработке начинается со сбора и анализа требований. Как правило, на данном этапе методолог выполняет всестороннее изучение особенностей предметной области, проводит ряд встреч с сотрудниками клиента. В результате должны быть сформированы требования к разрабатываемому продукту. На основании данных требований будет проводиться тестирование и приёмка готового программного продукта.
Затем разработчик проводит анализ требований и сопоставляет их с возможностями выбранного «коробочного» решения. На данном этапе, необходимо определить, что может быть реализовано с использованием стандартного функционала, а что необходимо доработать. В процессе подготовки технического задания разработчик активно взаимодействует с методологом по вопросам уточнения отдельных требований. В случае большого объёма доработок и риска увеличения сроков или бюджета проекта методолог совместно с клиентом может изменить отдельные требования.
После утверждения технического задания происходит процесс непосредственной настройки и доработки стандартного функционала. Работа должна выполняться блоками со сдачей на тестирование промежуточных результатов. По мере завершения разработки методолог проверяет соответствие программного функционала требованиям. В случае выявления несоответствия программный продукт возвращается на доработку.
По завершению процесса разработки и внутреннего тестирования готовое решение демонстрируется клиенту. В случае принятия работы начинается процесс внедрения. Данный процесс «стартует» с обучения сотрудников клиента. Затем происходит введения нормативно-справочной информации и «сквозной» прогон работы программы.
После завершения внедрения запускается процесс поддержки, в ходе которого сотрудникам клиента оказываются консультации по работе с программой и, при необходимости, выполняются доработки функционала.
В данной статье проведен детальный анализ диаграммы и отзывов клиентов, который позволил выделить «узкие» места в процессе «Оказание услуг по веб-разработке» компании, что в свою очередь, привело к построению диаграммы «как должно быть». Так как изменения являются глобальными и затрагивают основополагающую деятельность компании, было принято решение о проведении реинжиниринга бизнес-процесса. Чтобы оценить результаты реинжиниринга были сформулированы цели и, с использованием методологии SMART, критерии достижения цели.
Список использованных источников:
SMART [Электронный ресурс]. - Режим доступа URL: https://ru.wikipedia.org/wiki/SMART (дата обращения 15.12.2020).
Каскадная модель [Электронный ресурс]. - Режим доступа URL: https://ru.wikipedia.org/wiki/Каскадная_модель (дата обращения 16.12.2020).
Матричная структура управления [Электронный ресурс]. - Режим доступа URL: https://port-u.ru/postroeniestruktury/matrichnayastruktura (дата обращения 16.12.2020).
Несвоева А.А. Анализ текущей реализации бизнес-процессов компании, занимающейся разработкой программного обеспечения // Материалы XIII Международной студенческой научной конференции «Студенческий научный форум» [Электронный ресурс]. – Режим доступа URL: https://scienceforum.ru/2021/article/2018024994 (дата обращения 15.12.2020).
Реинжиниринг: сущность и методология [Электронный ресурс]. - Режим доступа URL: https://www.cfin.ru/management/strategy/change/reengineering_methodology.sht ml (дата обращения 16.12.2020).
Цели и критерии управления [Электронный ресурс]. - Режим доступа URL: http://managment-study.ru/celi-i-kriterii-upravleniya.html (дата обращения 16.12.2020).
Цикл Деминга или PDCA [Электронный ресурс]. - Режим доступа URL: https://skinbox.ru/media/management/tsikl_deminga/ (дата обращения 15.12.2020).