Как автоматизированно управлять разработкой продуктов

Как автоматизированно управлять разработкой продуктов

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

Постановка задачи

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

Содержательная часть

В ЦРИТ ведется разработка АСУ МС — информационной подсистемы многоуровневой системы управления и обеспечения безопасности движения поездов (МС). Главное назначение АСУ МС — автоматизированное обеспечение соблюдения технологии работы железнодорожного транспорта (как отдельных хозяйств, так и системы управления перевозками в целом) путем сбора, обработки и анализа соответствующей информации. АСУ МС — большой комплексный проект. Общее число этапов работ над проектом АСУ МС Свердловской ж.д. более ста, привлечено более десяти соисполнителей: Микротест, ОЦВ, «Железнодорожные технологии», «Инфотэкс AT» и др.

Для решения задачи управления проектом АСУ МС в ЦРИТ использован пакет программ MS Project™, предложенный Фирмой Microsoft®, который позволяет:

• обеспечивать технологию управления проектом независимо от уровня сложности;

• осуществлять максимальную автоматизацию рутинных операций и улучшенный пользовательский интерфейс;

• расширять доступность и осуществлять координацию при работе над проектом;

• оперативно и согласованно вносить изменения в план проекта и параметры его фактического состояния независимо от удаленности участников проекта;

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

С помощью пакета программ MS Project™ ЦРИТ контролирует как работу соисполнителей, так и работы, проводимые сотрудниками самого центра. В реализации проекта предусматриваются три главные фазы:

• контроль (отслеживание, трэкинг) за реализацией плана и управления проектом;

На рис. 1 показан фрагмент сетевого графика разработки АСУ МС на Свердловской железной дороге.

Для эффективного распределения ресурсов в программе MS Project™ предусмотрено ресурсное планирование проекта.

Ресурсное планирование позволяет:

• оценить потребность в ресурсах конкретного типа;

• спланировать рациональное распределение потребности в ресурсах во времени;

• определить участки проекта, являющиеся критическими с точки зрения потребностей в ресурсах;

• оценить суммарную стоимость проекта;

• контролировать расходование ресурсов при реализации проекта.

Рис. 1. Сопровождение проекта АСУ МС на Свердловской железной дороге.

Рис. 2. Домашняя страница MS Project™ на сайте АСУ МС.

Рис. З Сетевой график.

Для удобства пользования и просмотра необходимой информации для всех участников проекта в сети Intranet через сайт АСУ МС (10.200.1.188) был реализован доступ к домашней странице (Рис.2) и к сетевому графику (Рис.З).

После изучения пакета программ в ЦРИТ решено использовать следующие возможности пакета:

• оценка стоимости проекта;

• контроль сроков выполнения проекта;

• контроль объема выполнения работ;

• анализ выполнения проекта;

• анализ и оптимизация загрузки ресурсов;

• согласование плана проекта;

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

Таким образом, в ЦРИТ накоплен положительный опыт сетевого планирования работы над комплексными проектами с использованием современных информационных и Web-технологий.

Как мы автоматизируем процесс разработки

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

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

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

Это подтверждает исследование Coralogix — разработчик в среднем на 1000 строк кода допускает 70 ошибок. Для их исправления требуется минимум в 30 раз больше времени, чем на кодинг.

Как было раньше

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

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

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

Первые шаги со «Студия 1.0»

Мы решили делать low-code систему, которая потребует минимум разработчиков высокого уровня, и будет понятна технологам, ранее никогда не писавшим код. Обычно подобные проекты используют визуальные интерфейсы с простой логикой и функциями drag-and-drop для прописывания жизненного цикла. Код подставляется в автоматическом режиме.

Чтобы визуально представить low-code систему, можно вспомнить среду для быстрой разработки Delphi 7. С ней многие читатели могли познакомиться ещё в школе или вузе. Для создания элемента достаточно было перетащить его на поле рабочий области. Он тут же прописывался в теле программы и оставалось лишь закодировать логику.

В «Студии 1.0» принцип был схож с Delphi 7, но только описывать логику уже было не нужно. Из имеющейся базы подтягивался написанный метод, который ранее использовался на проектах. Важно отметить, что мы не собирались полностью отказываться от труда программистов. Если технолог не находил нужный код, то разработчик, обслуживающий проект, дописывал недостающие куски самостоятельно. С каждой итерацией инструмент становился мощнее.

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

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

С этим low-code решением нам удалось сократить количество высокоуровневых разработчиков, которые работают над проектами, на 44%. А также уменьшить время разработки и тестирования готового продукта.

Автоматизируем разработку со «Студия 2.0»

В первой версии «Студии» мы не смогли уйти от необходимости передавать задание от бизнес-аналитиков к системным аналитикам. Но уже сейчас разрабатывается интерпретатор требований, который парсит техническое задание от бизнес-аналитиков и адаптирует его для разработчиков. Модуль умеет работать с популярными форматами файлов от офисных пакетов. Бизнес-аналитикам не придётся менять привычные инструменты.

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

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

Модуль саморазработки постоянно обновляется и обрастает новыми возможностями и методами реализации. Он является главным отличием от первой версии «Студии». Модуль позволит нам в будущем добиться максимальной автоматизации.

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

«Студия 2.0» оптимизирует затраты на тестирование, так как нет смысла делать отладку после работы автоматизированной системы.

Куда идём дальше

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

Отдельно список требований будет сформирован для подтверждения заказчиком. Он экспортируется в привычные офисные форматы DOC или XLS. Процесс займёт не больше времени, чем выпить чашечку кофе.

В будущем планируем сделать «Студию» кроссплатформенной. То есть отвязать её от платформы «ОПОРА», где она сейчас работает, и подключать к другим системам. Это как раз то, чего не хватает многим продуктам автоматизированной разработки.

Намечен план развития до 2023 года. «Студия» уже сейчас используется для решения коммерческих задач компании ОТР. Но со временем мы отдадим её и во внешнее пользование.

• low-code
• разработка
• автоматизация
• автоматизация разработки

УПРАВЛЕНИЕ РАЗРАБОТКОЙ И УПРАВЛЕНИЕ ПРОЕКТАМИ: ПРОТИВОПОСТАВЛЕНИЕ ИЛИ ДОПОЛНЕНИЕ? Текст научной статьи по специальности «Экономика и бизнес»

УПРАВЛЕНИЕ ПРОЦЕССАМИ / УПРАВЛЕНИЕ РАЗРАБОТКОЙ / ОРГАНИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ / ТЕХНОЛОГИИ РАЗРАБОТКИ ПРОГРАММ / ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ / АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ / ПОДДЕРЖКА ПРИНЯТИЯ РЕШЕНИЙ / АВТОМАТИЗАЦИЯ УПРАВЛЕНИЯ / ОПТИМИЗАЦИЯ ПРОЦЕССА РАЗРАБОТКИ / УТОЧНЕНИЕ ТЕРМИНОЛОГИИ / DECISION SUPPORT / AUTOMATED SYSTEMS / SOFTWARE / SOFTWARE DEVELOPMENT TECHNOLOGIES / DEVELOPMENT PROCESS ORGANIZATION / DEVELOPMENT MANAGEMENT / PROCESS MANAGEMENT / CONTROL AUTOMATION / OPTIMIZATION OF THE DEVELOPMENT PROCESS / CLARIFICATION OF TERMINOLOGY

Аннотация научной статьи по экономике и бизнесу, автор научной работы — Тиханычев Олег Васильевич

Предметом исследования является процесс разработки программного обеспечения автоматизированных систем управления. Объект исследования — средства организации разработки программного обеспечения . Общепризнанное перспективное направление повышения эффективности применения организационно-технических систем — автоматизация управления ими. Существенную долю эффективности любой сложной технической системы обеспечивает её программное обеспечение. В первую очередь это относится к прикладному программному обеспечению. Разработка прикладных программ сопряжена с определёнными трудностями, в первую очередь — организационного характера. Обобщённый анализ показал, что в мировой практике существует достаточно широкий спектр средств организации процесса разработки программ. Эти средства предлагается разделить на две крупные группы относительно отношения к процессу и степени детализации на «средства управления проектами» и «средства управления разработкой». Каждое из средств эффективно для тех или иных условий разработки программного обеспечения . В обзорной статье проведён анализ факторов, влияющих на эффективность применения того или иного средства, синтезированы предложения по целесообразности использования различных систем управления в разных условиях процесса разработки. Анализ показал, что для условий разработки прикладного программного обеспечения автоматизированных систем поддержки принятия решений наибольшую эффективность обеспечивает комплексное применение средств автоматизации управления процессами

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по экономике и бизнесу , автор научной работы — Тиханычев Олег Васильевич

О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений
Пользовательские интерфейсы в автоматизированных системах: проблемы разработки
Исследование роли научно-технического сопровождения в разработке программных продуктов АСУ

Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений

Управление ключевыми процессами iт-компании
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

DEVELOPMENT MANAGEMENT AND PROJECT MANAGEMENT: CONTRAST OR COMPLEMENT?

The subject of this research is the process of developing software for automated control systems. The object of research is the means of organizing software development. A generally recognized promising direction for increasing the efficiency of the use of organizational and technical systems is the automation of their management. A significant share of the effectiveness of any complex technical system is provided by its software . This primarily applies to the application software . The development of application programs is fraught with certain difficulties, primarily of an organizational nature. The generalized analysis showed that in world practice there is a fairly wide range of tools for organizing the program development process. These tools are proposed to be divided into two large groups with respect to the attitude to the process and the degree of detail on «project management tools» and «development controls». Each of the tools is effective for certain conditions of software development. The review article analyzes the factors affecting the effectiveness of the use of a particular tool, synthesized proposals on the expediency of using various control systems in different conditions of the development process. The analysis showed that for the conditions of the development of applied software for automated decision support systems, the most effective is the integrated use of process control automation tools.

Текст научной работы на тему «УПРАВЛЕНИЕ РАЗРАБОТКОЙ И УПРАВЛЕНИЕ ПРОЕКТАМИ: ПРОТИВОПОСТАВЛЕНИЕ ИЛИ ДОПОЛНЕНИЕ?»

Программные системы и вычислительные методы

Правильная ссылка на статью:

Тиханычев О.В. — Управление разработкой и управление проектами: противопоставление или дополнение? // Программные системы и вычислительные методы. — 2020. — № 2. DOI: 10.7256/2454-0714.2020.2.29603 URL: https;//nbpublish.com’library_read_article.php?id=29603

Управление разработкой и управление проектами: противопоставление или дополнение?

Тиханычев Олег Васильевич

кандидат технических наук заместитель начальника отдела, ГК «Техносерв 111395, Россия, г. Москва, ул. Юности, 13

Статья из рубрики «Автоматизация проектирования и технологической подготовки производства»

Дата направления статьи в редакцию:

Предметом исследования является процесс разработки программного обеспечения автоматизированных систем управления. Объект исследования — средства организации разработки программного обеспечения. Общепризнанное перспективное направление повышения эффективности применения организационно-технических систем -автоматизация управления ими. Существенную долю эффективности любой сложной технической системы обеспечивает её программное обеспечение. В первую очередь это относится к прикладному программному обеспечению. Разработка прикладных программ сопряжена с определёнными трудностями, в первую очередь — организационного характера. Обобщённый анализ показал, что в мировой практике существует достаточно широкий спектр средств организации процесса разработки программ. Эти средства предлагается разделить на две крупные группы относительно отношения к процессу и степени детализации на «средства управления проектами» и «средства управления разработкой». Каждое из средств эффективно для тех или иных условий разработки программного обеспечения. В обзорной статье проведён анализ факторов, влияющих на эффективность применения того или иного средства, синтезированы предложения по целесообразности использования различных систем управления в разных условиях процесса разработки. Анализ показал, что для условий разработки прикладного программного обеспечения автоматизированных систем поддержки принятия решений наибольшую эффективность обеспечивает комплексное применение средств автоматизации управления процессами

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

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

Для повышения эффективности разработки ПО в настоящее время используются различные методологии: «гибкие» Agile, «каскадные» Waterfall, их варианты -Ш.

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

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

На практике указанные методологии применяются через систему прикладных технологий и набор реализующего их инструментария. В рамках этих технологий, как в программировании, так и в других областях деятельности, для повышения эффективности рабочих процессов в практике управления принято использовать различные средства автоматизации управления коллективами разработчиков (Team Foundation Server — TFS, Jira, Gemini, Savana, Redmine, Trac, TaskJuggler, Toyota Kanban, Microsoft Project, Wrike, Confluence).

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

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

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

чего предпринята в данной статье.

1.Особенности средств управления проектами и разработкой программ

Как показывает опыт применения средств автоматизации управления коллективами разработчиков, в том числе лично автором, при одинаковом функционале они могут различаться областью применения. Например, TFS или Jira применяются при управлении разработкой программных продуктов [7,8], Toyota Kanban — при разработке

машиностроительной продукции А Microsoft Project, Wrike, Confluence или «Адванта» реализуют более широкий, но менее специализированный функционал и обеспечивают управление работой коллектива в целом. Конечно, есть отличия и внутри классов, например, между средствами управления разработкой программной продукцией и продукцией машиностроения. Наиболее заметное: при разработке промышленной продукции существенная роль возлагается на системы подбора по каталогам готовых деталей и типовых сборочных единиц, соответствующих требованиям к

разрабатываемому изделию [10’11]. При управлении разработкой программного продукта эти системы не используются по крайней мере, пока. Но перечисленные отличия определяются подходами к требуемому результату, да и то только в текущей ситуации. С переходом к промышленным методам разработки программного обеспечения, внедрением фондов типовых алгоритмов и программ, могут измениться и указанные функции. Указанные факты подтверждают актуальность проблемы уточнения классификации средств управления коллективами разработчиков.

Сравнивая особенности вышеперечисленных систем, можно сделать вывод, что многие проблемы выбора для использования тех или иных систем возникают из-за используемой в настоящее время терминологии их описания. Все системы управления коллективами разработчиков, принято обозначать термином, сформулированным на основе прямого перевода английского понятия «project management» (управление проектами). Формально это правильно. В то же время, исходя из функционала, логичнее часть из них назвать не системами управления проектами, а системами управления разработкой (development management). В данном случае речь идёт о средствах типа TFS и Jira, обеспечивающих не только управление самим процессом разработки, но и реализацию части технологических функций: тестирование, сборка программного продукта и т.п. [1214]. Уточнение терминологии позволит разделить и области применения инструментария, определив рациональность его выбора для реализации тех или иных функций и этапов жизненного цикла программной продукции Такой вывод позволяет сделать

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

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

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

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

«доской» работ, виджеты отображения хода выполнения проекта аналогичны и в TFS, и в Jira, и в других системах управления разработкой ПО. Похожи между собой и экранные формы различных систем управления проектами, их основные функции. А вот между формами программ управления проектами и управления разработкой внешнее сходство встречается реже. И даже в случае сходства, компоненты существенно различаются по реакции и содержанию функций (рисунки 1-3).

Рис.1. Внешний вид форм панелей задач систем управления разработкой TFS (наверху) и

Jira (нижний рисунок)

Рис.2. Внешний вид форм «досок» задач систем управления разработкой TFS (сверху) и

Jira (нижний рисунок)

Рис.3. Внешний вид аналогичных форм средства управления проектами Wrike

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

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

— по уровню формализации задач исполнителям проекта;

— по возможности взаимодействия со сторонними системами;

— по наличию встроенных средств автоматизированного тестирования и сборки программ.

По факту, хотя и те, и другие системы управляют работой персонала, оптимизируя использование наличных ресурсов и времени, системы управления разработкой в большей степени обеспечивают управление разработчиками и технологическими процессами, а системы управления проектами — руководство коллективами и маркетинговыми процессами [16,17,18].

2.Функциональные особенности средств управления разработкой и управления проектами

Процесс разработки ПО, в соответствии с требованиями нормативной документации, состоит из тех же этапов, что и создание автоматизированных систем управления, в составе которого оно реализуется:

— формирование требований, разработка концепции автоматизированной системы;

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

— разработка проектных решений по созданию системы в рамках эскизного и технического проектов;

— разработка опытного образца и рабочей конструкторской документации, приёмосдаточные испытания и сертификация системы;

— производство, ввод в действие;

— сопровождение эксплуатации системы.

Работа по каждому из этих этапов организуется в соответствии с типовым циклом управления: от целеполагания до постановки задач и контроля их выполнения.

Для реализации тех или иных функций типового цикла управления, на практике используется достаточно широкий перечень систем различного назначения: ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), BI-системами (Business Intelligence) графического представления данных, средствами командно-сетевого планирования (КСП-системы), PLM-систем (Product Lifecycle Management), систем автоматизированного тестирования (Automation Testing System — ATS), средствами интеграции приложений (EAI — Enterprise Application Integration) и других [19-21]. Наличие EAI является достаточно важным фактором, учитывая, что системы управления производством редко разрабатываются под конкретный проект, чаще используются готовые системы, имеющиеся в активе предприятия [22, 23].

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

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

Таблица 1 — Соответствие функционала систем управления процессами и разработкой возможностям других систем автоматизированного управления

Функция системы автоматизированного управления В системах управления про е кта ми В системах управления разработкой

Компоненты базы знаний (набора готовых решений) прое кта +

Средства автоматизированной сборки программ — +

Анализ указанных различий позволил определить, пусть в первом приближении, возможность и целесообразность использования компонентов перечисленных систем в тех или иных ситуациях работы над проектами по разработке ПО (см. таблицу 2).

Таблица 2 — Возможности использования средств управления процессами и управления

Используемые средства Параметры проектов Неавтоматизированное управление Использование средств управления разработкой, производством (TFS, Jira и др.) Использование систем управления про е кта ми (Microsoft Project, Wrike, Confluence и др.)

Масштабность Небольшие коллективы + — —

Крупные коллективы в рамках одного предприятия +

Совокупность коллективов разных предприятий + + +

Степень формализо-ванности Неформализованное описание цели и задач, неявно заданный результат + + +

Предельно формализованная задача с чётко заданным ре з ультато м ++ +/-

Структура про е кта Линейная, разнородная, с преобладанием уникальных компонентов +/- +

Р а з в е тв лё нна я , с параллельным работами и пов то ря ющ имис я элементами +/- + +

+ + означает высокую эффективность использования; + приемлемая эффективность;

— означает низкую эффективность применения технологии в данных условиях;

+ / — эффективность применения варьируется в зависимости от особенностей использования.

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

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

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

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

3.О практическом использовании средств управления проектами

Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на:

— системы управления проектами (project management);

— системы управления разработкой (development management).

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

Рис.4. Организация комплексного использования средств управления проектами и

Практика показала, что средства управления проектами и средства управления разработками — это эффективным инструменты как каждый в своей области, так и при совместном применении. Но, как всякие инструменты, они имеют границы применимости, в рамках которых они выдают ожидаемую эффективность. С другой стороны, при использовании вне указанных рамок (таблица 2), эти средства не просто показывают нулевой прирост эффективности, они мешают выполнению проекта, заставляя разработчиков выполнять лишнюю работу. Данный вывод сделан автором на основании практического опыта: когда в небольших коллективах на коротких проектах прямая постановка задач начинает дублироваться работой в TFS или Jira, аналитики, описав программисту процесс, вместо перехода к следующему этапу вынуждены повторно описывать уже выполняемые задачи. Что увеличивает затраты времени, практически не влияя на качество работы. И то, что результаты постановок задач фиксируются в электронной форме, служит слабой компенсацией потерянного времени.

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

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

«стейкхолдерами» (stakeholders), от английского понятия, обозначающего причастных к процессу лиц или организаций, непосредственно заинтересованных в его результате. Организация таких слоёв позволит управленцам всех уровней оперативно оценивать реализацию требований относительно разрабатываемой системы или её свойств, удовлетворяющих их потребностям и ожиданиям (стандарты ISO/IEC 15288:2015, ISO/IEC 29148:2011). Повышая тем самым эффективность контроля процесса разработки, как одного их важнейших этапов цикла управления. И, соответственно, обеспечивая оперативное реагирование на изменения в динамике производственного процесса, сокращая время и затраты.

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

электронных вычислительных машин и баз данных» [24,25], в том числе систем отечественной разработки: 1С-Битрикс24, «Адванта» (А2), «Rubius Project Manager», «Яндекс.Трекер» и множества других. Остаётся только выбрать средство, отвечающее требованиям конкретного проекта или организации по функционалу. После этого выбора остаётся организовать комплексное применение средств управления проектами и разработкой, которое, как показала практика, обеспечивает оптимизацию использования перманентно ограниченных сил и средств для решения ресурсоёмких задач. Оптимизацию, как по распределению ресурсов, так и времени на разработку программного продукта.

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

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

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

технической документации [26,27]. Это достаточно объёмная задача, но её решение обещает определённый прирост эффективности разработки ПО. Которое, в настоящее время, является неотъемлемой и очень важной частью практически любой сложной технической системы. Исходя из этого, решение сформулированной в статье научно-

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

1. Иванова. Г.С., Ничушкина Т.Н. Проектирование программного обеспечения. — М. : Изд-во МГТУ им. Н.Э. Баумана, 2002. — 74 с.

2. Майк Кон. Scrum: гибкая разработка программного обеспечения. Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). — М.: Вильямс, 2011. — 576 с.

3. Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика — М. : Вильямс, 2004. — 752 с.

4. Royce W. W.Managing the development of large software systems: concepts and techniques. Proceeding. ICSE ’87 Proceedings of the 9th international conference on Software Engineering. The Institute of Electrical and Electronics Egineers Inc., 1970. -pp. 328-328.

5. Тиханычев О. В. О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений // Программные системы и вычислительные методы. — 2018. — № 2. — С. 51-59.

6. Джефф Сазерленд. Scrum. Революционный метод управления проектами-Scrum. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2016. — 288 с.

7. Майк Кон. Пользовательские истории: гибкая разработка программного обеспечения (Signature Series). — М.: «Вильямс», 2018. — 256 с.

8. Рыбина Г.В. Проблемы интеграции и особенности разработки программного обеспечения современных интеллектуальных систем // Прикладная физика и математика. 2013. — № 3. — С. 41-63.

9. Шонбергер Р. Японские методы управления производством. — М. : Экономика, 1988. — 199 c.

10. ГОСТ 7.22-2003″Система стандартов по информации, библиотечному и издательскому делу. Промышленные каталоги. Общие требования»(введен в действие постановлением Госстандарта РФ от 29 мая 2003 г. N 167-ст). М.: Издательство стандартов, 2003. — 7 с.

11. Каталог деталей и сборочных единиц. Центр каталогизации и информационных технологий «Каталит». Официальный сайт. URL: http://katalit.ru/index.php?

option = com_content&.view=article&.id = 65&.Itemid = 144 (дата обращения: 17.09.2019).

12. Тиханычев О.В., Макарцев Л.В., Гахов В.Р. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. 2017. — №4. — С. 706-710.

13. Рекомендации по преподаванию программной инженерии и информатики в университетах. — М. : ИНТУИТ.РУ, 2007. — 462 с.

14. Выпасняк В. И., Тиханычев О. В. Автоматизированные системы управления войсками (силами): тенденции, методы и перспективы развития // Вестник Академии военных наук. — 2009. — № 4. — С. 61-68.

15. Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. — 2016. — № 4. — С. 27-35.

16. Хенрик Книберг. Scrum и XP: заметки с передовой-Scrum and XP from the trenches. C4Media, 2007. — 140 с.

17- Летбридж Т. [и др.]. SE2004: рекомендации по обучению специальности «Программная инженерия» // Открытые системы. СУБД. 2006. № 10. URL: http://www.osp.ru/os/2006/10/ 3910113 (дата обращения: 10.04.2017).

18. Кеннет Рубин. Основы Scrum: Практическое руководство по гибкой разработке ПО = Essential Scrum: A Practical Guide to the Most Popular Agile Process. — М.: «Вильямс», 2016. — 544 с.

19. Сныткин Т. И., Поляков А. Е., Руденко Г. А. Системное проектирование автоматизированной системы военного назначения с использованием нотаций Archimate 2.1. // Динамика сложных систем-XXI век. 2018. Т. 12. — № 2. — С.44-55.

20. Штрик А.А. Технологии и инструментальные средства создания программного обеспечения: состояние и перспективы // Программные продукты и системы. 1991. -№ 2. — С.57-64.

21. Вичугова А. А. Этапы, методы и средства конфигурирования информационных систем // Прикладная информатика. 2015. — №3(57). — С.88-99.

22. Gauch S., Chaffee J., Pretschner A. Ontology-based personalized search and browsing // Web Intelligence and agent systems. — 2003. — Vol. 1. — P. 219-234.

23. McAvoy, L. M., Chen, L., & Donnelly, M. (2012, September). An ontologybased context management system for smart environments. The Sixth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies, UBICOMM 2012, -pp. 18-23.

24. Постановление Правительства РФ от 16.11.2015 N 1236 (ред. от 20.11.2018) «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд» URL:

https ://reestr.minsvyaz.ru/upload/iblock/c00/2020_12_2017.pdf (дата обращения 19.04.2019).

25. О внесении изменений в Федеральный закон «Об информации, информационных технологиях и о защите информации» и статью 14 Федерального закона «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 188-ФЗ от 29.07.2015 г. URL: http://base.garant.ru/71108368/ (дата обращения 19.04.2019)

26. Барковский С.С., Янин Д.М. Особенности информационного обеспечения автоматизированных систем управления военно-научной работой // Тренды и управление. — 2015. — №4. — C. 441-449.

27. Гракова Н.В. Построение семантической модели управления проектами // Кибернетика и программирование. — 2012. — №1. — C.7 -15.

Результаты процедуры рецензирования статьи

В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.

Со списком рецензентов издательства можно ознакомиться здесь.

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

производстве, системы в машиностроительной промышленности, но без ссылок на публикации. Не приводится методология исследования. Не понятно насколько и на каком объеме материала Авторы проработали состояние вопроса, хотя упоминается что выводы во вводной части статьи основаны на личном опыте Авторов. Не упоминается объем материала, условия исследования, не структурированы задачи. В статье не сформулированы научные результаты, полученные Авторами, не приводятся критерии оценки. Рис. 4 является схемой взаимоотношения руководителя проекта и разработчиков, но её нельзя считать результатом работы. Для табл. 1 и 2 отсутствует анализ, поэтому читателю не ясно с какой целью они приведены. Это собственные результаты авторов или сводные таблицы по анализу публикаций. В статье много размытых формулировок и непоследовательного изложения материала, что затрудняет рецензирование. Много терминов, приведенных одновременно на русском и английском языках, необходимо ли это? Библиография достаточна, но все ссылки приведены не отдельными позициями, а группами (всего 5 групп, максимально ссылка на 8 позиций одновременно). Это позволяет усомниться в детальной проработке Авторами результатов других исследований в данной области. Стиль изложения материала. В статье используется терминология, однако встречаются просторечные и сленговые выражения. Много пунктуационных ошибок. Многие предложения не имеют логического окончания. Необходимо привести структуру статьи в соответствие с требованиями к научным работам, повысить четкость формулировок. Представленные материалы нуждаются в существенной доработке и после этого могут быть опубликованы в виде обзорной статьи.

Результаты процедуры повторного рецензирования статьи

В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.

Со списком рецензентов издательства можно ознакомиться здесь.

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

распространением программных систем и комплексов в различных отраслях современной экономики и, соответственно, необходимостью изучения, проектирования и оптимизации средств управления коллективами разработчиков программного обеспечения (управления проектами и управления разработками). Научная новизна связана с полученными авторами выводами о том, что для обеспечения эффективного и комплексного использования средств автоматизированного управления проектами и разработкой требуется уточнить их классификацию. Предложено разделить данные системы по их функциональному назначению — средства управления проектами и управления разработкой. Стиль изложения научный. Статья написана русским литературным языком. Структура рукописи включает следующие разделы: Введение (программное обеспечение (ПО), требования к срокам и качеству разработки, методологии — «гибкие» Agile (гибкая модель), «каскадные» Waterfall (каскадная модель), их варианты, система прикладных технологий и инструментария, средства автоматизации управления коллективами разработчиков, проблема классификации систем управления технологическими процессами относительно их функционального назначения, задача уточнения классификации методов управления коллективами разработчиков), 1.Особенности средств управления проектами и разработкой программ (опыт применения средств автоматизации управления коллективами разработчиков,

различия областей применения — TFS или Jira, Toyota Kanban, Microsoft Project, Wrike, Confluence, «Адванта», терминология описания систем, перевод английского понятия «project management» (управление проектами), системы управления разработкой (development management), сравнительный анализ характеристик средств автоматизации управления разработкой — управляющие компоненты, входные и выходные формы программ, внешний вид форм панелей задач систем управления разработкой, «досок» задач систем управления разработкой TFS, Jira и Wrike, функционал систем управления коллективами разработчиков — по уровню формализации задач исполнителям проекта, по возможности взаимодействия со сторонними системами, по наличию встроенных средств автоматизированного тестирования и сборки программ), системы управления разработкой и проектами), 2. Функциональные особенности средств управления разработкой и управления проектами (процесс разработки ПО, типовой цикл управления, спектр систем различного назначения, соответствие функционала систем управления процессами и разработкой возможностям других систем автоматизированного управления, использование средств управления процессами и управления разработкой, небольшие коллективы), 3. О практическом использовании средств управления проектами (уточнение классификации систем управления коллективами разработчиков — системы управления проектами (project management), системы управления разработкой (development management), организация комплексного использования средств управления проектами и разработкой, совместное использование средств управления проектами и разработкой, создание тематических слоёв отображения состояния управляемого процесса (stakeholders), проблемы в использовании указанных средств, спектр средств управления проектами), Заключение (выводы), Библиография. Текст включает три рисунка, две таблицы. Содержимое рисунков практически не читается. Обозначения в таблицах 1, 2 ( + , -, —, + + , -/+, +/-) следует пояснить. Слово «Вариант / Варианты» из названий таблиц можно изъять. Содержание в целом соответствует названию. В то же время обращает внимание, что речь идёт, в основном, о классификации, сходстве и различиях в функционале, дополнении систем управления проектами и разработкой. В тексте упоминается, что «при использовании вне указанных рамок (таблица 2), эти средства не просто показывают нулевой прирост эффективности, они мешают выполнению проекта, заставляя разработчиков выполнять лишнюю работу», однако данное положение не подтверждено дополнительными аргументами, что представлялось бы целесообразным. Также не вполне ясно, что понимается автором под stakeholders — возможность создания тематических слоёв отображения состояния управляемого процесса, сами тематические слои? Обычно стейкхолдерами (англ. stákeholder — заинтересованная сторона, причастная сторона) называются физические лица или организации, имеющие интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям. Библиография включает 27 источников отечественных и зарубежных авторов — монографии, научные статьи, материалы научных мероприятий, нормативные правовые акты. Библиографические описания некоторых источников нуждаются в корректировке в соответствии с ГОСТ и требованиями редакции, например: 1. Иванова Г. С., Ничушкина Т. Н. Проектирование программного обеспечения. — М. : Изд-во МГТУ им. Н. Э. Баумана, 2002. — 74 с. 2. Кон М. Scrum: гибкая разработка ПО (. ). — М.: Вильямс, 2011. — . с. 4. Royce W. W.Managing the development of large software systems: concepts and techniques // ICSE ’87 : proceedings of the 9th international conference on software engineering. — Место издания . Год издания . — Р. 328-338. 5. Тиханычев О. В. О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений // Программные системы и вычислительные методы. — 2018. — № 2. — С. 51-59. 9. Шонбергер Р. Японские методы управления производством.

— М. : Экономика, 1988. — 199 c. 13. Рекомендации по преподаванию программной инженерии и информатики в университетах. — М. : ИНТУИТ.РУ, 2007. — 462 с. 14. Выпасняк В. И., Тиханычев О. В. Автоматизированные системы управления войсками (силами): тенденции, методы и перспективы развития // Вестник Академии военных наук.

— 2009. — № 4. — С. 61-68. 15. Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. — 2016. — № 4. — С. 27-35. 22. Gauch S., Chaffee J., Pretschner A. Ontology-based personalized search and browsing // Web Intelligence and agent systems. — 2003. — Vol. 1. — P. 219-234. Для источников №№ 10, 23 нужно указать выходные данные. Апелляция к оппонентам (Иванова Г. С., Ничушкина Т. Н., Кон М., Мартин Р. С., Ньюкирк Дж. В., Косс Р. С., Тиханычев О.В. Сазерленд Дж., Рыбина Г. В., Шонбергер Р., Макарцев Л. В., Гахов В. Р., Выпасняк В И., Тиханычев О. В., Лукинова О. В., Книберг Х., Летбридж Т., Рубин К., Сныткин Т. И. Поляков А. Е., Руденко Г. А., Штрик А. А., Вичугова А. А., Барковский С. С., Янин Д. М. Гракова Н. В., Royce W. W., Gauch S., Chaffee J., Pretschner A., McAvoy L. M., Chen L., Donnelly M. и др.) имеет место. Замечен ряд опечаток: Для повышения эффективности разработки ПО в настоящее время используются различные методологии: «гибкие» Agile (гибкая (ПОВТОР) модель), «каскадные» Waterfall (каскадная (ПОВТОР) модель), их варианты; тестирование, сборка программного продукта и т.п [12,13,14] — тестирование, сборка программного продукта и т.п. [12-14]; (рисунки 1, 2, 3) — (рисунки 1-3); [16,17,18] — [16-18]; [19,20,21] — [19-21]; Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на; — Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на: (ДВОЕТОЧИЕ); Существует достаточно широкий средств управления проектами — Существует достаточно широкий СПЕКТР (. ) средств управления проектами. В целом рукопись соответствует основным требованиям, предъявляемым к научным статьям. Материал представляет интерес для читательской аудитории и после доработки может быть опубликован в журнале «Программные системы

и вычислительные методы» (рубрика «Автоматизация проектирования и технологической подготовки производства»).

Как автоматизировать управление проектами на предприятии с помощью отечественных IT-решений

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

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

Проектная ERP — центральный пульт управления развитием производственной компании

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

Вот как выглядит типичная картинка предприятия до внедрения единого автоматизированного инструмента управления проектами:

• Разрозненное ведение проектов без общих правил и без учета общих ресурсов.
• «Зоопарк технологий» — используются разные ИТ-решения, никак не связанные с остальными.
• Проектная документация хранится в разных источниках.
• Бизнес-процессы непрозрачны и контролируются с трудом.

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

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

Барьеры внедрения автоматизированных систем управления на промышленных предприятиях

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

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

«Красный якорь»: как добиться прозрачности в проектах и автоматизировать всё за 5 недель

Один из последних кейсов по внедрению проектной ERP мы реализовали совместно с заводом «Красный якорь». На сегодняшний день это единственное в России предприятие по производству якорных цепей и такелажа, цепей для горно-шахтного оборудования, грузовых цепей, строп и комплектующих.

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

Чтобы реализовать предложенную стратегию развития, предприятию было необходимо решить ряд проблем, существующих на момент внедрения системы управления проектами. Вот лишь некоторые из них:

• Проекты управлялись изолированно, а формальные правила их ведения не соблюдались.
• Не было единой формы отчетов и хранения проектных документов и данных.
• Преобладало ручное управление: многие отчеты собирались вручную, а результаты хранились в виде обычных Excel-таблиц.
• Отсутствовали удобные дашборды, которые помогают видеть и контролировать ситуацию.

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

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

От внедрения ИТ-системы ожидали следующих результатов:

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

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

1. Занесли все пилотные проекты в систему.

2. Настроили автоматический сбор данных о состоянии проектов, сформировали ключевые отчеты по задачам, проектам и поручениям.

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

4. Настроили отчет для отражения загрузки сотрудников.

5. Настроили дашборды – визуальные панели управления для топ-менеджеров с заданным набором показателей.

Настроенное решение. Дашборд «Здоровье портфеля проектов»

В результате внедрения удалось создать удобный инструмент контроля за проектами в «одном окне». Трудозатраты на сбор отчетности и планирование новых проектов сократились на 60%. У исполнителей появилась возможность прозрачного планирования своей загрузки, а у руководства — оперативного контроля и принятия важных стратегических решений.

Заключение

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

27 показов
1.5K открытий
4 комментария
Развернуть ветку

Есть пару вопросов:
1. Не понятно за счет чего добились показателей, только лишь за счет того, что куда-то занесли информацию по проекту и настроили вывод дашбордов?

2. Не понятно суть статьи:
2.1 Если хотели показать какие крутые — то не совсем понятно за счет чего эта крутость
2.2. Если хотели рассказать про продукт, то совсем нет информации про продукт. Что это эксель, bi-система или кастомная разработка?

Развернуть ветку

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

Развернуть ветку

2. Про продукт частично есть ответы в самой публикации. В целом, ADVANTA — это не Excel, но она содержит в себе Excel-таблицы как отчеты.
BI — business intelligence — система, которая позволяет интерпретировать большие данные. Такой функционал в нашей системе тоже есть, к примеру, дашборды (интерактивные панели управления для руководителей с ) или сложные отчеты с большим набором параметров.
Кастомная разработка — да, это тоже про систему ADVANTA. Кастомизация заключается в том, что систему можно настроить под разные бизнес-процессы и задачи конкретного заказчика без программирования.
Это как раз объектная модель, отчеты/диаграммы/дашборды, которые можно настроить для каждого клиента индивидуально.
ADVANTA покрывает все процессы проектного управления и решает актуальные задачи компаний для успешной реализации проектов:
• поддерживает актуальный статус и собирает информацию по проектам
• автоматизирует процессы управления
• повышает контроль дисциплины и соблюдения правил
• дает инструменты для планирования ресурсов
• формирует актуальный Cash Flow и БДР по проектам
• снижает сроки и трудоемкость подготовки отчетности
• упрощает коммуникации, согласования, работу с документами