Хочешь цифровизироваться? Как поступить? На самом деле вариантов не много:
1. Мечта бизнесмена. Купить коробочку, или лучше скачать что-то бесплатное. Это не требует умственных затрат, дешево и быстро. Сотрудники потом сами на рабочем месте разберутся. Вот только эта идиллия разрушается при столкновении с реальностью. Или бизнес-процесс немного не тот, или коробочка не все делает так, как нужно. И начинается процесс долгой настройки. Делается это бессистемно, на коленке и побыстрей. В результате модификация приводит к ошибкам и отказам. Если коробочек несколько, то оказываться, что перенос данных из одного в другой требует сложных ручных алгоритмов. Через несколько лет это всем надоедает и закупается новая коробочка с софтом и все начинается снова.
Метод работал и будет работать, когда бизнес небольшой, быстро не растет и имеет множество стандартных бизнес-процессов (магазин, кафе и т.п), а также в случае автоматизации трудоемких локальных процессов разрабатывать софт для которых слишком затратно (дизайнер, видеомонтажер, архитектор).
2. Инициатива снизу. Найти умного сотрудника, который автоматизирует основные процедуры. У метода один большой плюс - автоматизация не сложного рутинного процесса, для которого нет стандартного коробочного решения. Недостатков много:
- Сотрудников, способных писать не много. Принципы разработки и современные технологии они не знают, в средствах разработки и в обучении они ограничены, самым популярное среди них средство - MS Access.
- Полученная система имеет множество ошибок и ограничений. Бывает невозможно увеличить количество пользователей и количество функций.
Есть недостатки и для сотрудника. Можно быстро достигнуть пределов своих возможностей. Разработка и поддержка ПО начинает занимать все больше времени. В результате сотрудник покидает компанию, так как не имеет сил совмещать два вида деятельности.
10-15 лет назад такая методика цифровизации была распространена. В медленно развивающихся организациях такое ПО работает до сих пор, в других эти модули становятся частью больших информационных систем. Мне кажется, что такая методика цифровизации или умерла или умрет в ближайшее время.
3. Пригласить "варягов". Нанять программиста или группу разработчиков в штат. С точки зрения заказчика, наверное, лучший вариант. Неограниченный доступ к экспертам по бизнес-процессам со стороны команды, возможность контроля со стороны заказчика, оперативная корректировка техзадания. Методика позволяет добиться лучших результатов. Вот только заказчик сам себе все портит:
- Руководство бизнеса должно понимать, что такое разработка программного обеспечения. Традиционная иерархическая система в разработке софта работает плохо. Скрам - лучший вариант для управления, но в обычном бизнесе он применяется редко.
- Не надо экономить. Дешевый или неопытный разработчик пишет плохой код. Бесплатные программные компоненты часто неудобны, работают медленно и содержат много ошибок.
- Жесткие сроки. Непродуманный код - ошибки и проблемы с масштабированием. Особенно это опасно на начальном этапе. Ошибки архитектуры потом крайне сложно исправить.
- Жесткие параметры системы. во-первых, опять проблемы с масштабированием - при изменении условий бизнеса может потребоваться глубокая модернизация системы. Во-вторых, невозможность применения современных средств и практик разработки.
Вот здесь бы и пригодился инициативный рационализатор из второго варианта, он и бизнес знает и немного в разработке ПО разбирается, но его либо выгнали, либо сам ушел. Приходится искать новых, но масса профессионалов уже сталкивались с такой ситуацией и не спешат повторения. Придется выбирать из неопытных, которые не прошли эту школу.
4. Нанять. Оптимальный вариант для разработчиков. Попадает заказчик, так как большой риск получить не то, что заказывал. Причин этого много:
- Заказчик и разработчик не могут написать техническое задание, или ТЗ написано с ошибками. Заказчик раздражается, что разработчик спрашивает о какой-то мелочи, а разработчик раздражается, что заказчик не дает нужную информацию. Проблема в психологии: заказчик думает типовыми (наиболее вероятными) процессами, но при разработке надо лучше учесть все варианты. Может этот случай один из 1000, но если он приведет к краху в самый ответственный момент, то кому-то будет сильно неприятно! Знание исключений хорошо сказывается на масштабировании системы в будущем.
- Разработчик продает типовой продукт. Берется типовой продукт и адаптируется под заказчика. Экономя ресурсы адаптируются и бизнес-процессы заказчика, и сам продукт. - Используемая для разработки "базовая" система очень редкая и поддерживать ее может только разработчик. Результат - вечное общение с разработчиком.
- Заказчику сложно выбрать разработчика. У всех разработчиков отличные сайты, все кому-то что-то делали (и даже некоторые были довольны).
Если откинуть всякие кафешки, магазинчики, коллективы фотографов и видеорежиссёров, то основная тенденция в бизнесе - интегральные решения. Это снижает трудоемкость бизнес-процессов, упрощает анализ деятельности компании. Однако вариативность рынков и бизнес-процессов компаний не дают возможности внедрения стандартных решений без их глубокой переработки, поэтому больше на рынке преобладают решения под номерами три и четыре, когда системы пишутся под конкретную компанию.
1. Мечта бизнесмена. Купить коробочку, или лучше скачать что-то бесплатное. Это не требует умственных затрат, дешево и быстро. Сотрудники потом сами на рабочем месте разберутся. Вот только эта идиллия разрушается при столкновении с реальностью. Или бизнес-процесс немного не тот, или коробочка не все делает так, как нужно. И начинается процесс долгой настройки. Делается это бессистемно, на коленке и побыстрей. В результате модификация приводит к ошибкам и отказам. Если коробочек несколько, то оказываться, что перенос данных из одного в другой требует сложных ручных алгоритмов. Через несколько лет это всем надоедает и закупается новая коробочка с софтом и все начинается снова.
Метод работал и будет работать, когда бизнес небольшой, быстро не растет и имеет множество стандартных бизнес-процессов (магазин, кафе и т.п), а также в случае автоматизации трудоемких локальных процессов разрабатывать софт для которых слишком затратно (дизайнер, видеомонтажер, архитектор).
2. Инициатива снизу. Найти умного сотрудника, который автоматизирует основные процедуры. У метода один большой плюс - автоматизация не сложного рутинного процесса, для которого нет стандартного коробочного решения. Недостатков много:
- Сотрудников, способных писать не много. Принципы разработки и современные технологии они не знают, в средствах разработки и в обучении они ограничены, самым популярное среди них средство - MS Access.
- Полученная система имеет множество ошибок и ограничений. Бывает невозможно увеличить количество пользователей и количество функций.
Есть недостатки и для сотрудника. Можно быстро достигнуть пределов своих возможностей. Разработка и поддержка ПО начинает занимать все больше времени. В результате сотрудник покидает компанию, так как не имеет сил совмещать два вида деятельности.
10-15 лет назад такая методика цифровизации была распространена. В медленно развивающихся организациях такое ПО работает до сих пор, в других эти модули становятся частью больших информационных систем. Мне кажется, что такая методика цифровизации или умерла или умрет в ближайшее время.
3. Пригласить "варягов". Нанять программиста или группу разработчиков в штат. С точки зрения заказчика, наверное, лучший вариант. Неограниченный доступ к экспертам по бизнес-процессам со стороны команды, возможность контроля со стороны заказчика, оперативная корректировка техзадания. Методика позволяет добиться лучших результатов. Вот только заказчик сам себе все портит:
- Руководство бизнеса должно понимать, что такое разработка программного обеспечения. Традиционная иерархическая система в разработке софта работает плохо. Скрам - лучший вариант для управления, но в обычном бизнесе он применяется редко.
- Не надо экономить. Дешевый или неопытный разработчик пишет плохой код. Бесплатные программные компоненты часто неудобны, работают медленно и содержат много ошибок.
- Жесткие сроки. Непродуманный код - ошибки и проблемы с масштабированием. Особенно это опасно на начальном этапе. Ошибки архитектуры потом крайне сложно исправить.
- Жесткие параметры системы. во-первых, опять проблемы с масштабированием - при изменении условий бизнеса может потребоваться глубокая модернизация системы. Во-вторых, невозможность применения современных средств и практик разработки.
Вот здесь бы и пригодился инициативный рационализатор из второго варианта, он и бизнес знает и немного в разработке ПО разбирается, но его либо выгнали, либо сам ушел. Приходится искать новых, но масса профессионалов уже сталкивались с такой ситуацией и не спешат повторения. Придется выбирать из неопытных, которые не прошли эту школу.
4. Нанять. Оптимальный вариант для разработчиков. Попадает заказчик, так как большой риск получить не то, что заказывал. Причин этого много:
- Заказчик и разработчик не могут написать техническое задание, или ТЗ написано с ошибками. Заказчик раздражается, что разработчик спрашивает о какой-то мелочи, а разработчик раздражается, что заказчик не дает нужную информацию. Проблема в психологии: заказчик думает типовыми (наиболее вероятными) процессами, но при разработке надо лучше учесть все варианты. Может этот случай один из 1000, но если он приведет к краху в самый ответственный момент, то кому-то будет сильно неприятно! Знание исключений хорошо сказывается на масштабировании системы в будущем.
- Разработчик продает типовой продукт. Берется типовой продукт и адаптируется под заказчика. Экономя ресурсы адаптируются и бизнес-процессы заказчика, и сам продукт. - Используемая для разработки "базовая" система очень редкая и поддерживать ее может только разработчик. Результат - вечное общение с разработчиком.
- Заказчику сложно выбрать разработчика. У всех разработчиков отличные сайты, все кому-то что-то делали (и даже некоторые были довольны).
Если откинуть всякие кафешки, магазинчики, коллективы фотографов и видеорежиссёров, то основная тенденция в бизнесе - интегральные решения. Это снижает трудоемкость бизнес-процессов, упрощает анализ деятельности компании. Однако вариативность рынков и бизнес-процессов компаний не дают возможности внедрения стандартных решений без их глубокой переработки, поэтому больше на рынке преобладают решения под номерами три и четыре, когда системы пишутся под конкретную компанию.
Комментариев нет:
Отправить комментарий