Комментарии 27
Как "такой" клиент могу назвать причины
Размазывание ответственности
Утеря компетенции приводящая к "ритуалам".
Отсутствие связи между уровнями из-за перегруженности(зачастую бесполезными делами) работников.
Нет никакого бизнеспроцесса есть куча людей делающих его части без осознания как оно работает в целом.
Попытка навести порядок как правило вызывает дикое сопротивление вплоть до увольнения работников с полной потерей знания как оно работало
Утеря компетенции приводящая к "ритуалам".
Воооот. А мне тут в соседней статье вкручивают — "да не надо нам знать, почему так, у нас карго-культ отлично работает..."
Наверно лучший ответ о причинах.
Согласен, но частично. Согласен с тем, что есть такие проблемы, но не согласен с какой-то обреченностью, которую, как мне кажется, уловил в вашем комментарии. Если это не так, то извините, значит показалось. Но тем не менее попробую описать то, с чего можно было бы начать решать эти проблемы. Пойду снизу вверх:
1. Про “дикое сопротивление, вплоть до увольнения”. Саботаж при введении новых систем и процессов, со стороны рядовых сотрудников, это распространенная проблема. Но благодаря этому также есть много возможностей, как повлиять на своих сотрудников.
Первое с чего стоило бы начать – узнать с чем вообще связано недовольство. Главное выделить те проблемы, которые чаще всего встречаются. Это могут быть как объективные проблемы (как “новая система/процесс увеличивают время решения задач или делают их менее удобными, чем было раньше”) или субъективные проблемы (утрировано “не нравится цвет кнопок” или просто “пофиг, что новая система автоматизирует рутинные задачи, мне в экселе было удобнее”). В идеальном мире, это можно было провести на начальных этапах работы с проектом. Но мы живем в нашем мире и хорошо бы такое исследование проводить хотя бы в процессе работы, когда доработки займут минимум времени и рисков.
С объективными проблемами, думаю, что все понятно. Собираем данные, анализируем и вносим их в роадмап проекта. Тестируем и смотрим на реакцию сотрудников.
А вот с субъективными проблемами будет сложнее. Нужно копать не в сами отзывы, а скорее в то, с чем вообще связан негатив. В то на сколько выстроены процессы (да, вы писали, что их нет и об этом также напишу ниже), как выстроена культура в команде, на квалификацию сотрудников (может они действительно могут только гугл таблицу открыть и там вручную что-то повносить). Также стоит посмотреть на то, какие есть группы сотрудников и интересы у этих групп. Я видел как хорошие проекты “падали” просто за счет того что внутри компании заказчика есть разные “политические силы”. И кому-то было просто выгодно, чтобы ничего не менялось.
Также посмотрите на то, как вы донесли до сотрудников важность новых систем и процессов. Провели ли обучение и на сколько качественным оно было. На сколько сотрудники поняли как это должно работать и как это повлияет на их работу. Улучшит ли новое их рабочий опыт?
2. “Нет бизнес процесса”. Не хочу показаться грубым, но начните выстраивать процессы. Пропишите регламенты, что, как, куда и зачем. Изучите методологии работы, которые есть. Посмотрите что вам лучше подойдет и облегчит работу сотрудников, сделает ее понятной и логичной. Только не гонитесь за модными agile и т.п. Выбирайте то что подойдет под ваш бизнес. Поймите самую суть ваших процессов, того как они должны работать, какой путь должен проходить лид или отдельная задача. Где образуются “узкие места”. Выстраивайте процессы по чуть-чуть и начните с самых важных.
Основных задач, при выстраивании процессов, я вижу две: упростить/ускорить процессы для сотрудников и сделать их прозрачными для менеджмента.
Первое позволит снять лишнее напряжение с сотрудников. Сделать так, чтобы они не тратили кучу энергии и времени на постоянное переключение между задачами/вкладками/типом действий (переключение между чем-то тоже можно рассматривать как часть процесса) и на то, чтобы постоянно разбираться в том, чего они не знают или не понимают. Чем понятнее и точнее описаны задачи, тем проще их решать и тем выше вероятность их эффективного решения.
3. По отсутствию связей и перегруженности. Это также к процессам. Если вы не понимаете как должна двигаться задача и где они агрегируются. На каком-то человеке/отделе, то вы не сможете с этим разобраться.
4. “Утеря компетенции и переход к ритуалам”. Поговорите со своими сотрудниками. Поймите с чем это связано. Почти наверняка выйдите на нерабочие или неэффективные процессы. Когда человек, который умеет круто продвигать задачи вынужден “перекладывать данные из одной эксельки в другую” или когда “эффективный менеджер оказывается просто самодуром, которому лень искать точки роста и он просто ставит задачи ради задач”. Вариантов может быть масса.
Также, если поговорить с сотрудниками, то может оказаться, что кто-то из них знает как решить проблему. Хотя бы локально, на своем месте или в отделе. Соберите и проанализируйте такие предложения, посмотрите что “бьется” с вашим видением процессов, с тем как оно работало бы эффективнее и начните внедрять это.
Также важно помнить, что процессы это не про то чтобы было удобно именно вам или не про то чтобы копировать то как “у дяди Пети”, а про то чтобы именно ваш бизнес начал работать с высоким кпд.
5. “Размывание ответственности”. У вас же каждая задача имеет исполнителя и проверяющего? Ведь так? Если да, то вы должны понимать кто и за что отвечает.
А ваши сотрудники, почему они “размазывают ответственность”? С чем это связано? Если случился провал по задаче, вы как-то его прорабатываете? Если да, то как? Завязаны ли провалы на деньги или какие-то еще формы “кнута”?
Самое главное здесь понять почему это происходит. Вопрос в сотрудниках, в организации процессов или в руководителе? В любом случае, это будут полезные данные.
Тут интересная тема поднята, но глубина и близко не раскрыта, увы. Прежде всего, операционка может делиться на ту, где ключевое преимущество, и тут, где просто должна быть, ибо должна быть (мне очень зашла фраза одного спикера на конференции, когда он говорил, что есть innovations to lead и innovations to survive, и что работать с этими кейсами нало принципиально по-разному).
Если мы говорим о реально сложной системе, решающей реально сложный вызов, требующий систему такой сложности, то логично, что ее владелец/идеолог/руководитель никогда не будет знать, как она работает, ибо такие системы обладают глубиной и скоростью эволюции большей, чем мозг этого человека: пример, приходит к Вам Сэм Альтман, и говорит, что они в OpenAI совершенно не понимают, как работает GPT4 (то есть, она то работает, но вот, почему иногда бред выдает, не понимают), и предлагают Вам автоматизировать ее процессы, но понятным кодом. Чтобы генерацию каждого токена можно было на канбан-доске отследить. Увидеть, какое слово еще в процессе выбора из кандидатов, и каких, а какое уже отдано юзеру. Короче, в CRM уместить процесс от получения промпта нейросетью до выдачи ответа. Возьметесь? Заказчик то денежный, а задача простая, - это тебе не операционщики, которые не с той ноги встали, на каждый такт процессора ведь исходный код имеется, система строго по регламенту работает (правда, почему-то ее создатели не понимают процессов в ней, наверное, аналитики у них плохие, или в разработке бардак). Или, к примеру, имеем мы дело с B2B продажами для североамериканских топ-менеджеров (как Snowflake), сейлзы обхаживают каждого клиента, в гольф с ним играют. Сможет хороший основатель весь алгоритм такого сейлза описать, чтобы обучать по нему новых сейлзов и сразу их в бой кидать?
Если без сарказма, то я намекаю на то, что для системы достаточной сложности состояние, когда один человек не может в явном виде описать процесс это и есть норма, и попытки такие системы формализовать я видел - ничем хорошим они не кончались. Они приводили лишь к остановке эволюции системы и накоплению критического количества исключений. Кажется, понять границы формализации и есть вызов аналитика, а не "порядок навести" и переучить
Но есть и другая ситуация - когда процесс не является ключевой компетенцией (условно, в любом офисе есть процессы уборки, заказа кофе, чистки кондиционеров). И тогда может вполне выходить, что заказчик тоже не знает процесс. Не потому, что он сложен, а потому, что ему это нах не надо. Надо, чтобы бумага в туалетах не кончалась, и не важно, откуда она там берется. Более того, самый совершенный процесс мира по менеджменту запасов туалетной бумаги никак не сделает компанию конкуретнее на ее рынке. Но тут уже возникает другой вопрос - а надо ли эти процессы автоматизировать и программировать под заказчика? Может, проще зааутсорсить все целиком, например? Или, вообще, пойти с другой стороны - нанять в помощь начальнику отдела студента, умеющего чуть на питоне писать, и пусть развлекается с ним (я так, реально, один раз сделал, чтобы неключевыми процессами не нагружать разработчиков нужных).
И, что в итоге имеем? Когда ситуация такова, что заказчик реально должен знать процессы своей компании? Оно вообще, реально, нужно когда-то? Или через пятикратное "Зачем?" любое "хочу автоматизировать процесс Х" оказывается самодурством или локальной оптимизацией?
Если это был ответ на мой комментарий, то уточню
Речь не о том что нет человека который знает всю схему а о том что как взаимодействуют части схемы не знает вообще никто. И почему нужно делать то что делается тоже.
В полной аналогии с чат гпт или куда более древней "китайской комнатой"
Кстати, вот это вы верно заметили. Попытка "автоматизировать процесс на 100%" - почему-то является светлой мечтой менеджмента. Разумнее было бы автоматизировать то, что не имеет смысла каждый раз решать в индивидуальном порядке. А для остального - сделать простую и понятную процедуру эскалации на лиц, компетентных принимать решение. Но нет - делаются простыни процессов, тома инструкций. В результате, процесс необозрим, полностью непонятен никому, включая автора. Исполнители тихо матерясь, расписываются за знание процесса и идут придумывать как им теперь работать...
Опять же это будет зависеть от целей заказчика. От того как он понимает проект. Мы со своей стороны приложим все усилия, чтобы сделать проект эффективным. И много клиентов, которые либо “с ходу” приносят свое понимание процессов, понимают цели проекта и действительно хотят создать ценность. Либо во время работы над проектом формируют это понимание. И эти проекты потом радуют. Таких клиентов также много. С ними приятно работать.
Возвращаясь к кейсу, это может быть не то, что мы все представляем под процессом продаж, особенно продаж на потоке. Такая система будет учитывать особенности бизнеса.
Да и про “научить” я нигде не говорил. Про то, что подготовить команду клиента, внедрять продукт постепенно, а не “с двух ног”.
Но я понимаю чем вызван негатив. Сейчас много тех кто говорит или пишет как “истина в последней инстанции”. По типу “мы лучше знаем как должен работать бизнес клиента или заказанный им продукт”. Иногда да, опыт может подсказывать верные решения. Но это всегда совместное творчество. Когда мы хотим сделать так, чтобы клиент получил рост своих метрик эффективности, а мы долгосрочные финансовые отношения с клиентом.
У нас нет шаблонов “как надо”. Мы пилим проект под нужды и требования клиента. И готовы учитывать такие нюансы, как игру в гольф или походы в баню. :)) Спасибо за содержательный комментарий.
В статье я и не думал о глубине темы. Скорее описал свое личное восприятие.
Я с вами согласен, что можно было постараться раскрыть тему прийти к каким-то выводам. Просто хабр, для меня, выполняет скорее терапевтическую функцию. Иногда хочется поделиться своими мыслями и посмотреть на то, как на эти мысли или описанные ситуации реагируют другие участники комьюнити. Многие пишут классные и полезные мысли в комментах. Это здорово!
А так да, прочитал и призадумался. С одной стороны все верно, но если детализировать, то можно заметить ряд моментов, которые также стоит учитывать.
1. Пример с Open AI мне видится немного утрированным. То есть, теоретически можно было бы вообразить, что кому-то потребуется доска, на которой будет процесс генерации каждого промта. Но вероятность того, что такой проект кто-то захочет реализовать, тем более при помощи стороннего подрядчика, стремится к нулю.
Все же от количества процессов, их глубины и сложности также зависит и сам проект. Возможность возникновения потребности в проекте и поиск способов его реализации.
В статье я говорю о процессах, где есть четкие роли, задачи у этих ролей и этапы прохождения этих задач. Не миллионы промтов, а десятки, может сотни действий в день. Более приземленный проект.
Если утрировать, то можно придумать много примеров. Они будут нежизнеспособны, не применимы на практике. Но могут доказывать точку зрения. Мне приятно, что вы постарались изложить свою точку зрения и я бы предложил подискутировать более предметно.
Например, ваш второй кейс. Да, в нем есть ряд отхождений от классического процесса продаж. Но они также могут быть учтены. Мы можем включать или не включать сами эти действия в процесс. Это может быть что-то универсальное, например “Стадия переговоров”. Внутри этой стадии могут быть комментарии: “Клиент любит ходить в баню по субботам и такое-то пиво”. Эти данные мы можем положить в карточку клиента и учитывать в будущем. Ведь сейлз может уйти, а новому сейлзу придется заново выстраивать отношения с этим клиентом.
И это нас приводит к этапам построения процесса. От касания с клиентом и заведения его карточки в базу. И дальше по этапам продажи (индивидуально для данной компании: переговоры, отправлено КП, согласование условий и так вплоть до успеха или провала. Также мы можем ставить задачи в этой системе. Сводить данные по успехам и провалам. Какие менеджеры остаются на “стадии переговоров” и просто ходят в баню с клиентом, но не приносят никаких продаж. И т.д. и т.п.
Здесь речь не идет про то, чтобы всех поставить “к ногтю” и сломать то, что не работает. Сделать эффективнее - да. Понять процессы, найти их уязвимости и точки роста - безусловно.
Что вы имеете ввиду под формализацией, я понимаю. Такое тоже бывает. И зачастую этот процесс происходит на стороне клиента. Изначально цель проекта “формализовать процессы”, а по факту привести их под тот общий знаменатель, каким его видит “биг босс”. А он часто видит процессы как “да что там делать, пять минут и готов”. А это может быть что-то емкое. Вот тогда да, в таких проектах внедрение новой системы может быть неэффективно.
Но если посчитать, что проект не для освоения бюджета, каких-то личных целей менеджеров или других причин, а ориентированный именно на то, чтобы вырастить эффективность работы, то основным критерием успеха проекта будет упрощение работы сотрудников и прозрачное понимание процессов. Возможность оценить те же пресловутые точки роста, моменты провалов и т.п.
По процессам не являющимся ключевой компетенцией (уборка, кофе и т.п.). Ну, мы про них просто не говорим сейчас. Пока не встречал проект, в котором это были бы ключевые этапы процесса. Но если бы такой проект пришел, то можно было бы и его сделать. Почему нет?
Клиент хочет реализовать проект. Он видит в нем ценность. Мы соберем требования, проанализируем процесс, предложим решения. Подготовим документацию, утвердим и реализуем проект.
Надо ли автоматизировать процессы или лучше посадить студента со знанием питона? Да, все индивидуально. Справится студент с питоном, когда в компании много отделов и ролей в них, прав по записям или по операциям, пересекающиеся группы интересов, разные стадии, сегментация клиентов, проектов, есть разные активности, а сверху это все накрывается документооборотом? Маловероятно. А выдержит ли такая система нагрузку, сможет ли она масштабироваться? Тоже вряд ли.
Зааутсорсить тоже можно. Только, что вы вкладываете в это понятие? Мы вот, как внедренцы, тоже аутсорсом занимаемся. Или речь о том, чтобы зааутсорсить этапы работы, передавать рабочие документы, контакты клиентов? Мало кто бы на это согласился. Если отдать на аутсорс уборку и кофе, то да, вопросов не имею.
Должен ли бизнес знать процессы? Вопрос интересный. Зависит от уровней. Если мы говорим, должен ли гендир большого холдинга знать как конкретные сейлзы по скрипту работают? Нет конечно. Это был бы снова утрированный пример. А вот должен ли РОП знать как строятся продажи в его отделе – безусловно. Так и строится структура проекта. Кто-то ответственный от компании собирает требования от стейкхолдеров (РОПы, РОМы, РП, PR, менеджеры и т.д.). Каждый на своем месте. Каждый ответственен за свой “кусочек пирога”. Потом этот человек все сводит воедино и передает нам. Мы на всех этапах стараемся ему помочь.
Были ли идеальные проекты, когда получилось сразу реализовать проект, который закрывал бы 100% потребностей? Возможно. Но я не встречал такие. Круто, если получается закрыть 60-70%, потом будут доработки и оптимизация. Уточнение требований. Особенно когда РОП посмотрит на готовый проект и поймет что ему еще чего-то не хватает, оно жизненно необходимо, а он просто об этом забыл, при составлении требований. Такое постоянно происходит.
Должен ли знать сотрудник процессы своей компании? Нет, не должен. Но должен быть наделен полномочиями, которые позволят эти процессы “снять”, систематизировать и сделать ту работу, которая от него требуется.
Да и моя статья не столько про незнание процессов, сколько про обычную лень. Когда клиент не хочет собирать процессы, когда тех дизайн подписывается “не глядя”, а перед сдачей проекта выясняется, что “это не то, что нам надо”. Да и про много чего еще. Просто это проще объединить про “незнание процессов”. Потому что и внутри своих отделов, подразделений клиенты часто не знают что происходит.
Еще раз спасибо за комментарий! Я только начинаю писать. И тема, для меня, по своему, эмоциональная. Так что “интересная тема поднята, но глубина и близко не раскрыта, увы…” – меня немного взгрустнуло. Но ваш комментарий заставил меня поразмышлять. Вот, делюсь с вами, своими размышлениями.
Здравствуйте, здравствуйте! Всегда рад видеть человека, который с реальными клиентами в РФ общается. :-)
Мой опыт сильно пересекается с тем, что написано. Я вижу две причины:
Тотально безобразное качество менеджмента. До тех пор, пока студентам на кафедре менеджмента будут говорить, что они могут управлять чем угодно: от кофейни до атомной электростанции, и они этому будут верить (и что самое страшное - им будут верить их работодатели) - ситуация не изменится. Менеджеры рисуют красивый процесс "как в учебнике". Исполнители крутят пальцами у виска, но так как зарплату им платят за выход годного - придумывают свой процесс (иногда внешне как-то совпадающий с тем, что описывает начальник - в тех точках в которых начальник его проверяет). Начальник получая обратную связь от своего руководства что вверенное подразделение работает нормально - еще больше убеждается в своей способности "выстраивать процессы". Потом он сам учит этому других. Круг замыкается.
Культура производства, ориентированная на людей, а не на процессы. Это я уже не знаю - почему... В подсознании людей (и руководителей и исполнителей) сидит миф, что надо найти правильного человека, и все будет работать. Соответственно, все ошибки персонифицированы и наказываются (мотивация у нас такая: пряник черствый, и им тоже бьют). В результате, все - всем врут. Одни врут что моют оборудование согласно регламента. Другие врут что берут смывы как положено. Третьи пишут нужные цифры в журнал без анализа (ну или почти без анализа). Но на бумаге и в докладах - у всех все ОК. Как при этом никто не травится - загадка. То-ли кто-то консервантов кладет больше чем положено по рецептуре, то-ли бог все-таки дураков специально охраняет от неприятностей. Попытка заставить соблюдать все процессы в этой ситуации приводит к немедленному параличу переходящему в кому.
Что с этим делать ? Понятия не имею. Учить и повышать культурный уровень. Рано или поздно (не обольщайтесь - скорее поздно, особенно в условиях "военной экономики") человечество докажет что способно обучаться и становиться лучше...
надо найти правильного человека, и все будет работать
Кадры у нас решают всё.
Только в армии процессы выстроены так, чтобы быть устойчивыми к сколь угодно низкому качеству кадров... Но кадрам в таких процессах некомфортно.
Спасибо за комментарий. Согласен с вами.
По менеджменту, да. Тут проблема не только в том, что учат “управлять чем угодно”, а еще и в том, что многие “эффективные менеджеры” не стремятся понимать суть процессов, механизмов своих компаний, отделов и т.п. А вместо этого, устраивают политические игры или просто пытаются “выжать” все что можно. И делается это все не для создания ценности, в том числе своей, как профессионала, а для построения имитаций.
С культурой – в самое яблочко!
Правда не всегда и не все так плохо. Есть классные менеджеры, которые понимают и свои процессы и стараются генерить ценность. С ними приятно работать. Просто те о ком мы тут с вами пишем, требуют больше трудозатрат и сил. Поэтому их кажется больше.
Не один человек от клиента нужен, а несколько и желательно с пониманием своей области автоматизации бизнес процесса. Желательно не решать сразу задачу максимум, а решать задачу наиболее востребованную, в которой команда от клиента заинтересована.
Так обычное желание клиента - сделайте хорошо и не делайте плохо. Типа дайте мне кнопку "сделать хорошо", а я сам уже решу кто её будет нажимать.
К большому сожалению, далеко не всегда таковые есть. Бывает попросишь заказчика - обозначим его как "улитка номер 1" (ну вы поняли xD) еще кого-то подключить к обсуждению, а приходит "улитка номер 2". А бывает и так что "улитка номер 2" еще хуже чем "улитка номер 1" и что тогда делать - просить подключить "улитку номер 3"?
Потому что «крутой аналитик» врывается к менеджменту, а надо наоборот, к исполнителям. И задача «крутого» «аналитика» как раз разобрать из чего состоит этот винегрет, а не слушать красивые сказки, как видит эти процессы менеджмент, который на ходу уже в голове дополняет эти процессы и модернизирует.
Но тогда вопрос. Как “врываться к исполнителям”, если это проект клиента и он сам дает выделенного менеджера?
То есть для нас заказчик выглядит как определенный менеджер или некий комитет, через который решаются все вопросы. У нас есть регламенты и документация, которые позволяют лучше вникнуть в процессы клиента и проработать все проекты “на берегу”. Аналитики, как могут, вытягивают из клиента данные по процессам. Но этот набор регламентов и документов, которые согласуются с клиентом, иногда не гарантирует точного понимания процессов клиента.
В какой-то момент вообще, может оказаться, что проект, который создавался на протяжении полугода, совсем нерелевантен целям клиента. Мы совместно с клиентом начинаем копать и оказывается, что на этапе согласования представитель заказчика просто не прочитал технический дизайн, подписал его просто потому что “да что там делать?” А это проект с массой зависимостей, ролей и т.д. и т.п.
Или такой проект сваливается просто под действием внутренней политики компании клиента. Когда человек, который отвечает за внедрение, внутри компании клиента, не хочет, чтобы проект был сделан. Ему, по каким-то своим причинам, выгодно чтобы проект не был успешен. И это не будет озвучено вслух. Просто постепенно, в процессе работы, начнут происходить “странности” и чем дальше тем все “страньше и страньше”. Но это отдельная тема, по которой можно много чего рассказать. И сейчас не вижу смысла углубляться.
Еще есть nda (иногда доходит до полнейшего маразма, когда представитель клиента не может дать жизненно важную, для проекта, информацию), такие же проблемы с ИБ, саботаж на уровне пользователей проекта (рядовых сотрудников), проект, который изначально был для “освоения бюджета” и в компании никто, на самом деле, не заинтересован в его завершении, а еще интриги, скандалы, расследования. Да еще много чего бывает. Какие-то моменты реже, какие-то чаще.
Но бывает и обратная сторона. Есть клиенты, представители которых, действительно заинтересованы в успешном завершении проекта. И представители такой компании почему-то знают и процессы, и роли да и то, что не знают, быстро узнают и вносят в документацию.
Да, при этом невозможно сразу охватить все. Поэтому есть поддержка, обучение клиента и возможность “докручивания” проекта нашими силами.
Бывают такие клиенты. И их тоже не мало. Просто здесь пишу о том, что занимает больше сил и энергии. А значит и рефлексии, ей и делюсь.
Тут речь скорее не про “красивые сказки”, а про то какие внутренние цели стоят перед самой компанией и ее представителями. Какая у этих представителей компетенция, погруженность в рабочие процессы. Нужно ли такому “внутреннему внедренцу” создать видимость деятельности, заинтересован ли он в новом проекте или он получает какие-то преференции со старого решения и ему выгодно оставить “как есть”, даже если это тормозит всю компанию.
Ну и статья скорее про мой личный нытинг.
Отдаю лайфкак, безвозмездно, то есть даром :)
Идёте по цепочке исполнителей и далее копии их отчетов и excel табличек которые они используют. Ещё до кучи просите копи сколов которые они коллегам шлют. Вот вам и описание процесса как оно есть.
Откуда менеджер его знать может?
Кстати, желающим все автоматизировать- не получится. Компетенция компании хранится в неявном виде в головах работников. Это уже кучей исследований было показано. Так что заменить их формальным процессом не получится.
Единственное что можно сделать - это сотрудникам жизнь облегчить- чтобы данный было просто получать и отправлять.
Идея со статусами процесс вообще не работает. Вернее работает но есть 3 статуса:
Заявка поступила, заявка в работе, заявка обработана.
Остальное смысла не имеет.
Если бы заказчик знал свои процесы, он наверное давно сам все автоматизировал :) А если серьезно, то в процессе автоматизации многие процессы как раз и уточняются, совершаются чудесные открытия и меняются ТЗ.
Когда процессы не автоматизированы, они частно работают не по четко прописанному регламенту, а по принципу "нам тут нужен такой план или нужно вот эту штуку посчитать, сделай". То, что навыки реализации процесса фрагментированы и нет понимания целой картины - в данном случае естественно.
Если коротко, то получается, что вы для себя открыли, что в состав работ по автоматизации оказывается входит бизнес-анализ и реинжениринг, а не только разработка требований)
Это отдельная большая часть работы, которую сложно продать заказчику, поэтому можно использовать более легковесные техники, чем формальное моделирование процессов, например, Event Storming
По мне, так причин две:
1) потеря цели
2) замена цели
Дальше можно много писать, но и автор и уважаемые коллеги выше, все написали: переход на ритуалы, приход знакомых/родственников; замены работы на контроль в связи с ростом компании, ну и далее по списку. Ну и необходимость "делить поляну" при попытке любой, ЛЮБОЙ попытке навести порядок в конторе,например оптимизации или автоматизации, так как вопрос упирается в ответственность и принятие решений, в том смысле, что ЛИЧНАЯ ответственность, и отсутствие возможности ее "размазать" по коллегам. А так, все верно!
Что в статье, что в комментах - надо "автоматизировать" :) А зачем? Не, ну правда.
Вот есть состояние as-is. Все хорошо, бабки капают, куры несутся. Зачем что-то менять? Это ж деньги и немалые. Лицензии, услуги внедрения и кастомизации, поддержка потом. Может не получиться.
------------
Ответ прост. Дело не в процессах, а в том, что есть потенциал для оптимизации, которые либо приведет к сокращению затрат, либо к повышению доходов. Возможны оба бенефита. Иногда просто незлья перейти на "следующий уровень" развития, т.е. требуется инфраструктурный скачок. И главное, чтобы внедрение "отбилось". Поэтому дело вообще не в процессах, и не в их знании или незнании кокнретными людьми. Дело в том, можно ли чего-то тут улучшить с итоговым позитивным результатом.
Когда же люди думают об автоматизации - обычно в лучшем случае просто получается внедрить и все :) Без результата.
-----------
Про незнание. Надо различать знание у одного человека и "коллективное" знание. Знания конкретных людей почти всегда отличаются, и это нормально. "Коллективное" знание в одной голове - большая редкость. В доке - еще большая редкость.
Мне кажется, просто проблема в сборе требований. Если аналитик такой мачурный - странно не знать таких простых вещей, да и банально удивляться очевидным вещам
Заказчик не равно пользователь или участник процесса. Да, к сожалению такова реальность. В большинстве случаев (моем личном) я встречала заказчиков которые являются руководителями участников какого либо из процессов, а они имеют право не знать, как решается та или иная поставленная им задача, в целом его не должно «интересовать» каким методом исполнитель выполнить его задачу, ему нужен результат, чтобы все были при деле в рамках выделенного дедлайна . это и есть основная задача руководителя - руководить.
У заказчика может появиться желания что-то улучшить, автоматизировать или масштабировать если ему не нравится результат или его сотрудники ( участники процесса) жалуются на трату больших ресурсов. Улучшить SLA.
Поэтому и запросы от заказчика звучат типо : хочу кнопку которая сократит мне время на обработку заказа в х10.
Заказчик может думать, что процесс состоит из 5ти шагов, ибо он смотрит сверху на весь процесс разом, а участники могут от себя на каждом из шагов уходить в подпроцессы и не акцентировать на этом внимание, для них например пойти уточнить информацию у коллеги не является шагом процесса, а для аналитика такие слепые зоны очень важны.
в связи с чем, на мой взгляд, хороший аналитик должен :
Выявить истинную боль и потребность заказчика.
Узнать список участников процесса
Пойти к участникам и узнать как на самом деле выполняется тот или иной процесс.
всем хороших заказчиков ❤️
Работаю разрабом в госсекторе. Тут вообще цирк стабильно бывает такой:
Приходит заказчик, описывает что ему надо, аналитики прикидывают, пишут ТЗ, мы делаем.
Через условно месяц презентует заказчику, на что он радостно хлопает в ладоши и просит добавить ещё фич. И так может повторятся год, проект обрастает фичами и уже костылями, уже все его ненавидят.
В итоге дело идёт к предрелизному показу и.... Заказчик просто говорит любую вещь:
1) Слишком сложно, наш персонал не адаптируется
2) Очень много надо конфигурировать, у нас некому
3) Вообще любая причина, лишь бы не внедрять уже готовы и оплаченный продукт (дада)
И это не единичные случаи, это прям стабильная ерунда, особенно когда где-то меняется начальник и пытается показать бурную деятельность, автоматизацию, цифровизацию, вот это всё.
готовы и оплаченный продукт (дада)
Так оплатили же? Та какая вам разница, внедрят они его, или нет?
Ну, как сказать.. Часто это и правда штуки, которые могут в разы ускорить как внутренний документооборот (а с учётом неспешности любой казённой бюрократии), так и обслуживание граждан в каких то моментах.
Т.е. я говорю буквально о том, что многие такие вещи ставят цели вроде изменения бизнес процессов в плане оптимизации.
Было: тетя Клава, заведующая мастер-экселькой, которую сводит раз в неделю по понедельникам, если встала с той ноги.
Могло быть: задача сама направляется в нужное место, тащит за собой список документов и историю, отслеживает KPI сроков исполнения.
Ну как то так.
Публикации
Почему Заказчики не знают своих процессов?