Автоматизация бизнеса. Размышления и 13 советов-взгляд из скорлупы

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

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

Меня озаботил тот факт, что далеко не всегда заказчик готов платить за предварительный анализ бизнес-процессов и составление ТЗ перед началом разработки. Вернее в 90% заказчик не готов этого делать.

Почему так происходит?

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

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

Почему системы нормативов и правил нет в разработке ПО?

Ведь программное обеспечение сегодня отвечает за безопасность на АЭС, за работу медицинских приборов, за безопасность жилья, за тепло в наших домах, за сохранность личных данных и финансовых средств?

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

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

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

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

1) Изучите предмет автоматизации и посмотрите что предлагает рынок в разрезе ваших потребностей.

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

3) Поймите каких результатов вы ждёте от внедрения ПО.

4) Какая инфраструктура необходима для успешной интеграции? Какое железо? Какой вспомогательных софт? Какие есть варианты для замены железа и софта?

5) Какие специалисты должны быть вовлечены в проект с вашей стороны и сколько времени они должны тратить на проект?

6) Как вы будете взаимодействовать с исполнителем работ? Какой опыт у исполнителя? Делал ли он похожие проекты ранее?

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

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

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

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

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

12) Поймите как должен документироваться код, кто этим будет заниматься. Как вы будете поддерживать работоспособность системы?

13) Поймите как вы будете оценивать проделанную работу, кто будет разбираться с вашей стороны в коде и безопасности архитектуры? По каким критериям вы будете принимать ПО в эксплуатацию?

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

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

Если же вы видите в описанном сложности, то не скупитесь - наймите профессионалов, которые произведут такую оценку.

У меня все) Очень хотел бы услышать ваше мнение на счет введения нормативов по созданию ПО и регулирования деятельности в этой сфере...

2 комментария

Софт. Никогда в истории человечества не было ничего подобного. Софт - продукт, который нельзя потрогать, на он он и софт. Может мы просто не можем загнать в осязаемые рамки, то, что не можем "потрогать"? Как определить кретерии текучести воды? Вода и вода везде, одинаковая вода, как определить, достаточно ли она текучая для воды? Такая же штука - удаленная работа. До 21го века ни кто не делал ничего на расстояниях в десятки тысячь км. И причём массово, ведь на удаленке сегодня работают тысячи спецов. Возможно только со временем человечество уложит всё это в умах и сможет как-то упорядочить для начала, а уж потом определять рамки, границы,кретерии.

1
Ответить

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

Ответить