Финансовые потери на ИТ. Сегодня поговорим о них.

Каждый человек хотя бы раз в жизни сталкивался с такой ситуацией, когда потратил деньги, приобрел себе какую-то вещь, услугу, ценность, но не получил от этого удовольствия, потому что понял после покупки, что переплатил, и мог купить дешевле. Я однажды так купил автомобиль в автосалоне, и потом месяц морально страдал от того, что мог купить его на 20% дешевле, если бы провел детальную аналитику рынка сам, а не обратился к "профессионалам". На корпоративном уровне подобные потери случаются регулярно. Однако, как и в случае с обычным человеком, о том, что потери случились компания может даже не узнать. В большинстве случаев так и бывает. Заметны обычно вопиющие потери, которые горят красными цифрами в финансовой отчетности. В области информационны технологий, в малом и среднем бизнесе, наибольшими обычно являются потери незаметные, которые даже часто потерями никто бы и не подумал называть.

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

Напишите в комментариях, вы теряли деньги на ИТ, как вы можете назвать эти потери? Напишите в комментариях ✔️

А я в следующих постах классифицирую потери
Афанасьев PRO Цифровизацию | CIOaaS

✖️Виды потерь

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

Потери могут быть:

▶️Прямые, заметные, легко подсчитать

Например, сделали какой-то ИТ проект, а он по разным причинам оказался не нужен компании, или не дает тех результатов, которые от него ожидались. В этом случае все затраты на проект оказались потерями, легко посчитать.
🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥

↖️Прямые, заметные, сложно подсчитать

Например, реализуем какой-то ИТ проект, и в процессе реализации понимаем, что выходим за рамки сроков и бюджетов, которые заранее спланировали. Но мы не можем остановить проект, потому что нам нужны его результаты и принимаем решение продолжать вкладывать деньги и ресурсы в проект.
Часто бывает, что реальные затраты на проект и его реальные сроки реализации могут превышать плановые в разы или на порядок. В этот же пункт можно добавить активности/проекты, в которые вошли без изначального плана, по разным причинам. Обычно самая частая причина - "сейчас мы быстренько запилим этот простой функционал".
🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥

▶️Прямые, незаметные, сложно подсчитать

Тут наиболее яркий пример - сравнение между собой двух подрядчиков. Представьте, что вы проводите тендер и хотите сравнить между собой двух подрядчиков по стоимости их услуг. Какой показатель вы будете изучать? Скорее всего стоимость человеко-часа. Но брать в расчет только стоимость часа без учета качества этой работы абсолютно неверно. Программист, который будет стоить вам по 5 т.р. за час может быть в три раза производительнее, чем другой по 4 т.р. за час и сгенерирует вам меньше технического долга. Я не говорю, что всегда так будет, я говорю, что это возможно и надо оценивать оба этих показателя как минимум. Ближайшая аналогия - пытаться оценить финансовое состояние компании только на основании ее отчета Cash Flow, не глядя в бюджет и бухгалтерский баланс. Проблема для компании состоит в том, что стоимости часа сравнивать легко, а производительность почти невозможно, пока не поработаешь. Или нужна чья-то рекомендация. Поэтому платя по 4 т.р. за час, компания незаметно для себя переплачивает, причем сколько именно она переплатила, посчитать очень сложно.
🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥

В следующих публикациях поговорим о косвенных потерях, пишите в комментариях, если хотите что-то добавить⏬⏬⏬⏬

Афанасьев PRO Цифровизацию | CIOaaS

Продолжим о потерях:

▶️Косвенные, заметные, сложно посчитать

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

Скажете - сказочка? нифига, сплошь и рядом, постоянно встречаю такой тип потерь. У нас "аджайл", скажете вы? Отвечу, что за "аджайлом" в МСБ обычно и прячут неумение сформулировать задачу и спроектировать хорошее решение, поэтому реализация задач идет просто потоком вперемешку без форматирования на периоды, результаты, ресурсы. А самым обычным запросом к руководителю является - "нам не хватает рабочих рук, нам нужно взять в штат еще парочку программистов".

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

Афанасьев PRO Цифровизацию | CIOaaS

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

Прямые, заметные, легко посчитать

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

➡️Бросились решать локальную проблему вместо того, чтобы немного подумать и оценить задачу комплексно

➡️Ввязались в реализацию не представив конечной точки и ожидаемых результатов "на энтузиазме"

➡️Сотрудникам ИТ, ответственным за реализацию не хватило компетенций оценить сложность задачи и текущую и целевую архитектуру проекта

➡️Заказчикам не хватило масштаба мышления для постановки задачи на более стратегическом уровне, а хватило только описать боли, которые нужно срочно решить, чтобы их не поругало их руководство

➡️Бросились решать следствие, а не причину
Из-за нехватки компетенций использовали для решения задачи неподходящие ИТ системы и сервисы

Все это можно описать словами "плохо подумали в начале" и чаще всего не исправились и потом, когда столкнулись с проблемами.

Как же не допустить такого развития событий?

Как это ни банально, но совета всего два:

✅Держать в фокусе результат задачи и критерии его достижения, а каждую подзадачу проверять на то, приближает ли она нас к результату

✅Иметь в распоряжении компетентную команду, которая будет приближать вас к решению, а не отдалять от него (под компетенциями понимается как наличии всех необходимых навыков, так и уровень владения этими навыками)

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

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

Афанасьев PRO Цифровизацию | CIOaaS

Продолжаем о потерях

Прямые, заметные, сложно посчитать

Для такого типа проблем решение уже давно придумали еще до ИТ - это компетентное проектное управление. В мире ИТ кроме классического проектного управления, которое часто уничижительно называют Waterfall, есть еще так называемые Agile методологии, которые позволяют гибко менять вектор развития разрабатываемого/дорабатываемого ИТ продукта в зависимости от внешних условий или быстро меняющегося окружения. Подход в целом очень неплохой и в случае, когда команда работает над ИТ продуктом, затраты на который коммерчески обоснованы, это лучший подход. На крупных конференциях представители крупных компаний, занимающихся серьезными разработками часто отчитываются о своих успехах, работая именно в некоем варианте Agile. В случае с МСБ же этот подход часто оказывается неэффективным.

Причины? Вот они:

➡️Нет ресурсов на полноценную команду из 7-10 человек, работающую только над одним ИТ продуктом. Как правило, команда распределяется между несколькими ИТ системами и предугадать ее загрузку на каждом этапе часто сложно. К тому же, команда решает и вопросы развития и вопросы поддержки и оказывает консультацию пользователям

➡️Неумение (отсутствие опыта и/или квалификации) представить себе результат решаемой задачу сразу. По этой причине разработка напоминает ежика в тумане, который движется не по наиболее эффективному пути, а туда, куда виднее в этот момент времени. Часто эту некомпетентность пытаются скрыть за "сложностью задачи", "быстро меняющимися требованиями", "большим количеством требований и участников проекта" и другими аргументами. Хотя на самом деле нужно просто хорошо спроектировать решение. Аджайл не освобождает команду от проектирования решения, он ишь помогает гибко этот проект менять во времени.

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

➡️"Ввязались" в решение задачи, а она оказалась неподъемной для имеющихся ресурсов, а не сделать уже нельзя, пообещали, бизнес ждет - и задача переходит в вялотекущий процесс с постоянной сдвижкой сроков.

🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥

Есть что добавить? Пишите в комментариях ⤵️⤵️⤵️

Афанасьев PRO Цифровизацию | CIOaaS

Продолжаем о потерях

Выше в постах я писал о потерях, далее скажу о решениях.

Решения просты, но очень действенные:

✅Используйте подходы к разработке, которые будут эффективны именно для вашей компании и для вашего ИТ продукта, а не те, которые модны, хайповы и гремят на крупных конференциях под авторством крупных ИТ компаний

✅Убедитесь, что компетенций команды достаточно для решения вашей задачи. Заказчик - это тоже член команды и ему тоже может недоставать компетенций в постановке задачи, даже если это уважаемый ТОП менеджер. Если это так, значит ему нужно помочь и выделить ему в помощь аналитика, но только не такого, который будет за ним ходить, заглядывать преданно в глаза и записывать каждое слово, а такого, который быстро разберется в бизнес-процессе и сможет предлагать решения, задавать предметные и серьезные вопросы и уметь аргументированно говорить НЕТ Заказчику ради его блага.

🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥

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

🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥🫥

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

Афанасьев PRO Цифровизацию | CIOaaS