The post has been translated automatically. Original language: Russian
When they talk about IT projects, they usually show results.:
• unified
system
• Automated processes
• Beautiful interfaces
• growth of indicators
But they almost never show how it really happens.
And that's where
the fun begins.
How it all starts (spoiler: very optimistic)
In negotiations before the conclusion of the contract, the customer says:
"We
already have everything.
We have been on the market for 20-30 years.
The processes are honed.
We just need to automate it."
Sometimes version number 2:
"We have
TK, it just needs to be improved a bit."
It sounds
confident.
Almost perfect.
What is happening in reality
There really are processes.
But:
• some of
them exist only “in the head”
• the part works differently for each employee
• part of it doesn't work at all, but it's considered to be working
And the most interesting thing:
if
there are 50-150 people in a company,
then you don't have one process...
you have 50-150 versions of one process.
And the knowledge of key employees often lives only in their heads.
If a person leaves, a part of the business leaves.
The stage that everyone underestimates
At the start
, it seems that you can quickly move on to development.
In practice:
First
, we need to digitize business processes.
And then it begins:
• Collecting
the real picture
• analysis, “as is”
• Disputes between departments
• finding out who actually works how
And only then architecture appears.
Sometimes it takes more than one month.
And yes, this is the stage that:
- need to sell separately
- and do it before development
The data (or where it actually is)
In the negotiations:
"We have all
the data, we will transfer it or integrate it"
In reality:
•
Excel files
• tables “on someone's computer”
• notebooks
• and, of course, “in the head of the employees”
To make the system work:
The data is needed:
• find
• structure
• Digitize
• sometimes with the hands of the player (with the hands of the performer)
Manual input is unavoidable at the start
Waiting:
the system will automatically assemble everything and start working
Reality:
at the start, a lot is done by hand
Why:
• the data
was not structured before
• The sources are not related
• Processes are just being formed
Without this
stage, the system simply won't take off.
Who makes the decisions (and why it's important)
In the negotiations:
"We will allocate
people, we will coordinate everything"
In fact:
• there is no one
responsible
• There are 5-8 supervisors
• no one speaks the “technical language”
Finally:
• documents
are read together (terms of reference/design decision)
• decisions take a long time to make
• discrepancies appear
And then the classics:
"Let 's look directly at the system"
And if you agree to it:
Development turns into an endless
process “until everyone feels good”
Implementation (the most underrated part)
In the negotiations:
"We
have a strong team, the implementation will be easy"
In reality:
• There are no
internal drivers of changes
• employees are not motivated
• no one wants to change the usual process
And it begins:
executor
=developer + analyst + trainer + psychologist + sometimes company employee
Resistance and sabotage
This is no
exception.
This is the standard.
Especially when 50-150 users:
• Mass
education does not work
• People get distracted
• they forget
• return to old tools
And at the time of launch:
"we don't know how
to use it, you didn't teach us well"
What really works
Not mass
education.
But:
• Spot
work
• On-the-job training
• analysis of specific tasks
• Live implementation
With every employee.
Yes, for a long time.
Yes, it is difficult.
But this is the only way the system starts to live.
Learning is not a one-time thing
The system
is changing.
Processes are changing.
People change.
Therefore
, learning becomes an ongoing process.
Where is the value actually created?
Many people think:
the main thing is
development
But in reality:
• development
That's 30-40%
• implementation is 60-70%
Because:
you can
make an ideal system that no one uses
, and you can make an imperfect one that gives results.
The only difference is the implementation.
How do we approach this
We
stopped doing “just development” a long time ago.
For us, this is:
• immersion
in business
• working with processes
• working with people
• and only then technology
We work within teams.:
•
we enter the data together
• testing together
• we are rebuilding our work together
Until the system
becomes a part of daily work.
The main insight
Digital transformation is not about code. And not about beautiful interfaces.
It's about
changing how people work every day.
And that's exactly why:
Implementation is always more difficult than development. Implementation can cost more than development!
Когда говорят про IT- проекты, чаще всего показывают результат:
• единая
система
• автоматизированные процессы
• красивые интерфейсы
• рост показателей
Но почти никогда не показывают, как это происходит на самом деле.
А именно там
и начинается самое интересное.
Как всё начинается (спойлер: очень оптимистично)
На переговорах до заключения договора заказчик говорит:
«У нас всё
уже есть.
Мы 20–30 лет на рынке.
Процессы отточены.
Нужно просто это автоматизировать.»
Иногда версия №2:
«У нас есть
ТЗ, его просто нужно чуть доработать.»
Звучит
уверенно.
Почти идеально.
Что происходит в реальности
Процессы действительно есть.
Но:
• часть из
них существует только “в голове”
• часть работает по-разному у каждого сотрудника
• часть не работает вообще, но считается, что работает
И самое интересное:
если в
компании 50–150 человек,
то у вас не один процесс…
у вас 50–150 версий одного процесса
А знания ключевых сотрудников часто живут только у них в голове.
Уходит
человек — уходит часть бизнеса.
Этап, который все недооценивают
На старте
кажется, что можно быстро перейти к разработке.
На практике:
сначала
нужно оцифровать бизнес-процессы
И тут начинается:
• сбор
реальной картины
• разбор, “как есть”
• споры между отделами
• выяснение, кто вообще, как работает
И только потом появляется архитектура.
Иногда на это уходит не один месяц.
И да, это тот этап, который:
- нужно продавать отдельно
- и делать до разработки
Данные (или где они на самом деле)
На переговорах:
«У нас все
данные есть, передадим или интегрируем»
В реальности:
•
Excel-файлы
• таблицы “у кого-то на компьютере”
• тетрадки
• и, конечно, “в голове у сотрудников”
Чтобы система заработала:
данные нужно:
• найти
• структурировать
• оцифровать
• иногда руками внести (руками исполнителя)
Ручной ввод на старте неизбежен
Ожидание:
система всё автоматически соберёт и заработает
Реальность:
на старте многое делается руками
Почему:
• данные
раньше не структурировались
• источники не связаны
• процессы только формируются
Без этого
этапа система просто не взлетит
Кто принимает решения (и почему это важно)
На переговорах:
«Мы выделим
людей, всё согласуем»
По факту:
• нет одного
ответственного
• есть 5–8 руководителей
• никто не говорит на “техническом языке”
В итоге:
• документы
читаются вместе (техническое задание/проектное решение)
• решения принимаются долго
• появляются разночтения
А дальше классика:
«Давайте смотреть сразу в системе»
И если на это согласиться:
Разработка превращается в бесконечный
процесс “пока всем не станет хорошо”
Внедрение (самая недооцененная часть)
На переговорах:
«У нас
сильная команда, внедрение пройдет легко»
В реальности:
• нет
внутренних драйверов изменений
• сотрудники не замотивированы
• никто не хочет менять привычный процесс
И начинается:
исполнитель
=разработчик + аналитик + тренер + психолог + иногда сотрудник компании
Сопротивление и саботаж
Это не
исключение.
Это стандарт.
Особенно при 50–150 пользователях:
• массовое
обучение не работает
• люди отвлекаются
• забывают
• возвращаются к старым инструментам
И в момент запуска:
«мы не умеем
этим пользоваться, вы плохо обучили»
Что реально работает
Не массовое
обучение.
А:
• точечная
работа
• обучение на рабочем месте
• разбор конкретных задач
• внедрение “вживую”
С каждым сотрудником.
Да, долго.
Да, сложно.
Но только так система начинает жить.
Обучение это не один раз
Система
меняется.
Процессы меняются.
Люди меняются.
Поэтому
обучение становится постоянным процессом.
Где на самом деле создаётся ценность
Многие думают:
главное —
разработка
Но в реальности:
• разработка
это 30–40%
• внедрение это 60–70%
Потому что:
можно
сделать идеальную систему, которой никто не пользуется
и можно сделать неидеальную, которая даёт результат.
Разница
только в внедрении.
Как мы подходим к этому
Мы давно
перестали делать “просто разработку”.
Для нас это:
• погружение
в бизнес
• работа с процессами
• работа с людьми
• и только потом технологии
Мы работаем внутри команд:
• вместе
вводим данные
• вместе тестируем
• вместе перестраиваем работу
Пока система
не становится частью повседневной работы
Главный инсайт
Digital-трансформация это не про код. И не про красивые интерфейсы.
Это про
изменение того, как люди работают каждый день.
И именно поэтому:
Внедрение всегда сложнее, чем разработка. Внедрение может стоять дороже, чем разработка!
Share
