Все это справедливо при одном условии. если бы я мог вместо ЦРПТ выбрать другую компанию или осуществлять деятельность без неё. Ни того, ни другого я сделать не могу. ЦРПТ мне навязан.
ЦРПТ очень вежливо поставил людей на бабки. Заказали большое кол-во кодов на маркировку остатков. Срок внедрения системы перенесли на 01.07. Казалось бы, коды есть, время есть. Надо сейчас выгрузить коды из «Честного знака» и загрузить их в свою учетную систему. А вот нифига. Коды не выгружаются ни в pdf, ни в csv. При этом никаких сообщений об ошибке. Техподдержка отвечает, что «коды-то вы заказали, а вот их печать (сиречь и выгрузка с „Честного знака“) с 01.03 платная. 65 копеек за штуку.
В законе, на мой взгляд, нет никаких оснований для платной печати кодов, заказанных до 01.03 (п.49, абзац 5):
»Предоставление участникам оборота обувных товаров, осуществляющим маркировку средствами идентификации обувных товаров, введенных в оборот до 1 марта 2020 г., кодов маркировки остатков обувных товаров, необходимых для формирования средств идентификации, осуществляется оператором информационной системы мониторинга бесплатно."
Всю статью не прочитал. Понятно, что это реальные претензии реального человека по реальным проблемам. Но меня всегда «радует» подход индивидуума (без разницы: программиста, тестировщика, манагера) к обособлению от общей проблемы.
Вот человек пишет:
Ближе к делу рекомендую поменять суть задачи или вообще передать ее другой команде — больше всего я люблю именно такие неожиданно прилетающие проекты, с которыми не справились предыдущие подрядчики, а теперь нужно успеть во что бы то ни стало. Так, последние 5 дней перед релизом будут самыми продуктивными!
Понятно, да, неприятно. Но есть другие пути, когда предыдущая команда реально обделалась в последний момент? Другая команда была в состоянии на начальном этапе спрайта сказать: «Нет, я это сделать не могу, передайте другой команде»? Я не знаю, возможно у меня специфика провинциального городка, но я ни разу не видел программиста, который сказал бы: «Да, я это точно сделаю, и сделаю до такого-то числа». Вернее, по одной задаче такое может быть, по продолжительной работе — нет. Как правило, при вопросе о реальных сроках исполнения программист предпочитает не отвечать, а падать в обморок.
А уж когда сроки из команды программистов вытянуты, согласованы с заказчиком, но командой просорваны, то единственный ответ ты получаешь от программистов «Ну не шмогла я, не шмогла».
Как избежать? Мониторить работу команды. Но как? Ведь мониторинг — это сложно, это избыточно и вообще незачем:
Отчетность о выполненной работе должна быть максимально подробной. Если мне не придется отмечаться в паре систем трекинга времени (командном и общекорпоративном, например), я буду чувствовать, что мои усилия никто не ценит. Только дублирование информации обеспечит должный уровень ее сохранности! Желательно, чтобы и форма отчетности была разной.
И да, взяв принцип построения речи в статье могу добавить: «Никогда не давайте манагеру реальную оценку состояния дела. Почаще ему сообщайте, что количество кода не пропорционально количеству прошедшего времени, что измерить процент выполнения работы программистом никак нельзя, любые измерители неадекваты. И помните, что у вас всегда есть вариант при срыве сроков сказать: „ну не шмогла я, не шмогла“. Манагер добрый, он поймет.
И вот тогда манагеру в срочном порядке приходится искать другую команду, которая конечно же, выскажет свое неудовольствие по прилетевшей задаче. И опять сзлобный косячный менеджер виноват!
И да! Контора, в которой работает программист, должна в попу дуть программисту, следить, чтобы он не обиделся на неточное ТЗ, на сжатые сроки, на клиента. Все это чисто манагерские проблемы, не его. Только вот надо ещё чтобы зарплата была вовремя:
Отличная встряска — задержка зарплаты. Если деньги не придут вовремя, я точно вспомню, что я работаю ради денег, соберу мысли в кучу и начну работать лучше.
Она же никак не зависит от качества кода продукта, от соблюдения сроков, от кол-ва найденных заказчиком багов… Деньги — они же из воздуха. Хоп — и взялись!
Понятно, что это вечная тема для холивара.
Я не удаленщик. Работал когда-то на удаленке, на заказах. И проблема была такая: приходит задание в субботу: «Это нужно сделать в понедельник к 17-00». И ты думаешь: да в принципе, относительно несложно, займет примерно 6 часов. Но 20% задания я не знаю как делать. Надо на выходных погуглить, поготовиться". И в итоге ты в субботу садишься за комп, начинаешь читать, смотреть, пробовать. Вроде как не работаешь, а с другой стороны ни с ребенком погулять, ни с женой куда-то сходить. Потому как если ты нашел решение того, чего не знал, это надо проверить. И ты уже по факту работаешь в выходные. Не нашел решения — просыпаешься в понедельник с готовым стрессом про то, что у тебя есть срочное задание, которое ты можешь не выполнить в срок. И в следующий раз, когда тебе приходит задание перед выходными ты уже просто садишься и начинаешь его делать в субботу, в святой наивности, что «зато в понедельник я побездельничаю».
Наверное, я просто не умею себя организовать. Но у меня лично такая проблема.
Если и есть такие конторы — то грош им цена, и хорошо, если они этого человека не возьмут. В остальных компаниях реально демонстрируемая заинтересованность кандидата в вакансии — плюс для кандидата. Даже для вакансии грузчика.
Если Вы так ответите, то я бы, как работодатель, с Вами распрощался.
Работодателю нафиг неинтересно на самом деле, на что Вы жили и какой у Вас был доход. Работодателю интересно почему соискатель с определенным уровнем компетенций вдруг оказался на берегу. Это могут быть как положительные факторы для работодателя, которые соискатель счел неважными, так и отрицательные.
Например, ищется сотрудник с «активной жизненной позицией». Живчик, короче. И работодатель узнает, что за эти три года пробела соискатель открыл 2 бизнеса, один прогорел, второй выжил, но стал, допустим, неинтересен. Для определенных вакансий, где требуется постоянно искать что-то новое — это плюс. А соискатель мог просто решить: «один бизнес прогорел, что о нем рассказывать? Второй бизнес скучный, зачем о нем говорить?».
Или просто соискатель занимался чем-то не по профилю вакансии, так как не нашел в свое время работы по профилю и решил об этом не говорить в резюме. А работодателю важно знать, что соискатель — не лентяй, что его трудно сбить с пути.
Или другой вариант: выясняется, что соискатель перегорел на важном проекте и на важном этапе проекта просто свалил в Тибет «искать себя» (в реальной жизни у меня так было). Работодатель может усомниться в том, нужен ли ему такой работник.
В любом случае, работодателя интересуют мотивы
Я так понимаю, что претензия автора в том, что менеджеры некомпетентны и не нужны. Ну да, менеджер-передаст в чистом виде приносит малую ценность. Но таких практически не бывает. Их либо увольняют, либо фактически обходятся без них, типа: «Очевидно менеджер недостаточно точно сформулировал мне задачу, запишите мой сотовый, мы поговорим напрямую».
ТС, видимо, считает, что хороший менеджер должен быть компетентнее компетентного программиста, админа, аналитика и любого из тех, кем менеджерит. А уж ИТ-директор должен быть мегагуру во всем и сам и сервак поднять, разобраться, почему заявка на договор идет неправильным путем согласования и что не так с хранимой процедурой в MSSQL.
Только, почему-то эти программисты, админы, которые считают манагера лишним звеном в обморок падают, когда нужно пойти к директору и защитить бюджет подразделения. А уж про звонок клиенту с целью урегулирования конфликта и говорить не приходится. Почему так, не понятно. Ведь разговор с руководством, с клиентами, со смежными отделами, формирование бюджетов, планов, контроль исполнения — такая фигня, это каждый может, любой дурак справится…
Человека, который принимает решение о том, по какой версии бизнес-процессов нужно вести автоматизацию, если этих версий четыре (регламентированные; «как рассказали пользователи»; реальные, о которых никто не знает; те, которые могут получиться с учетом возможностей программного продукта) или больше.
Если проект небольшой и руководитель проекта компетентен — то да. А если проект большой? Как, допустим, руководитель проекта (ИТ-директор допустим) должен указать производству согласовывать ли сменно-суточное задание со службой главного диспетчера или ограничиться контролем исполнения месячного плана? У РП в таком случае нет ни таких полномочий, ни таких функциональных знаний. Я думаю, что такие решения должны приниматься коллективно членами управляющего комитета.
Вынести можно то, что уже смоделировано!
Как это видится? Моделируем, допустим, процесс «как есть» на основании интервью и утвержденного регламента. Сотрудник говорит, что отправляет заключенный договор в производство для включения в план и только А уже производство при недостатке материалов формирует заявку на закупку. А регламент говорит, что заключенный договор должен сразу попадать в отдел закупок, когда ещё производство расчет потребностей не сделало. И что тогда моделировать? Оба варианта? А если расхождений сотни? Сколько версий процессов будет? Нет, фиксировать несоответствие и решать его надо сразу.
Почему? Не понял.
Вы про «красный цвет»? Ну да, там есть определенные сложности со сломом иерархии, но это не значит, что они неустранимы. Просто это будет несколько сложнее, чем в других случаях. Но я бы не сказал, что шансов нет
Как у меня на проектах, где много функциональных блоков.
Скелет процессов, как описано выше в комментарии практически 1: основные процессы, вспомогательные, обслуживающие. Основные: продажи, закупки, производство и т.д., но только те процессы, которые напрямую отвечают за получение прибыли предприятия. Потом, когда закончили основные — идут вспомогательные: логистика, склады и т.д. Потом уже обслуживающие: ИТ, бюжетирование, казначейство, бухучет и т.д.
Это очередность обследования. дальше в каждом процесс идет разбивка на подпроцессы с формированием выходов и входов каждого из них. Важно по окончании моделирования одного процесса иметь все его входы и выходы. Т.к. при обследовании второго процесса, зависимого от первого, вы всегда сможете проконтролировать: а все ли, что производит 1 процесс нашло отражение во втором? Или наоборот, а все ли, что ждут на старте второго процесса готов дать процесс первый?
Кого Вы понимаете под руководителем проекта? На крупных проектах руководитель проекта несет политическую функцию и не в состоянии решить методологический вопрос. Разве что административно, не вдаваясь в детали.
Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.
Тут, ИМХО, нужно смотреть на уровень корпоративной культуры предприятия. Если она демократичная, то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.
Если культура административно-приказная — готовить протокол обследования, формализовывать разрывы, делать по каждому разрыву фикс решения. Я только не очень понял чем рассказ в комментарии выше отличается от фактической деятельности. Есть бумажный регламент. Есть рассказ ответственного сотрудника, по которому видно где есть несоответствия с формализованным документом.
С таким подходом реализовать проект сложно. В принципе, должно быть так, что «приходит человек, которому нет оснований не доверять». А ещё лучше, чтобы в результатах обследования был вовлечен топ-менеджмент. И тогда обследование — это повод для персонала конструктивно рассказать о том, что в текущих процессах не устраивает. Ибо низовой персонал очень часто носитель ключевой информации и лучше других может видеть где конкретно нужно вносить изменения.
В клубке не надо разбираться — запутаетесь. Нужно без особых ньюансов понять «как есть» и обсуждать «как хотелось бы». Я всегда в в предпроектном обследовании пытаюсь выстроить такой скелет:
1. Услышать как бизнес-процесс идет сейчас. От начальной операции до конечной. Если в обследовании принимает участие несколько человек, то очень важно проводить интервью структурно, а то беседа превращается быстро в обсуждение какого-либо одного наболевшего вопроса или в коллективный плач Ярославны с жалобами на начальство или другие подразделения.
2. После описания «как есть» укрупненно рассказать как это реализовано в предлагаемой системе сейчас. И вывести народ на разговор типа: «О! Круто! Нам как раз так надо» или «Не, это нам не подойдет, потому что...». И всегда добиваться, чтобы это «потому что» прозвучало.
3. Перечень озвученных «потому что» уже и есть перечень насущных проблем. Дополнить его ответами на вопрос «а что бы Вам ещё хотелось видеть в системе» — и вот они укрупненные требования к автоматизации.
С проектным обследованием примерно так же, но детализация процесса и разговор намного глубже.
Чувствуется, наболело.
Вы правы и неправы одновременно. Если заказчик из первой группы, то Вы же сами говорите, что он наймет кого-то на изменение бизнес-процессов. Но что такое изменение? Это как раз моделирование, их реализация и аудит процесса в эксплуатации. А какая в современном мире реализация бизнес-процессов может обойтись без автоматизации? Вот я как раз об этом и говорил: интегратор может взять на себя функцию моделирования, если у заказчика своих потенций нет. Ну и уж точно берет на себя функцию реализации и, частично, последующего аудита.
Что касается большинства. Я уже про это писал выше: если принести все заказчику «на блюдечке», то принести ему в таком случае можно разве что «чемодан без ручки». Это та ситуация, когда заказчик говорит: «не знаю как, но сделайте мне красиво» и если интегратор на такой заказ соглашается, то берет на себя все охрененные риски того, что невовлеченный заказчик получит в итоге результат его устраивающий и применимый в его бизнесе.
Как избежать комплекса вины у заказчика? Нет никаких инструментов кроме одного: всяческими доступными средствами держать заказчика вовлеченным в проект все 100% времени жизни проекта. 100% вовлеченным. Я понимаю, что это про то, что «лучше быть здоровым и богатым, чем бедным и больным», но иначе никак.
Утрированно: как Вы вытираете дома пыль? Поднимаете предмет, проводите тряпкой под ним, ставите обратно? Или увидев, что предмет стоит не на своем месте относите его на место правильное? Вы же вроде пыль вытирать собирались, а не расставлять предметы по местам.
Именно. Это как раз та идея, которую я не смог продать на одном крупном проекте. Что смоделированные процессы «как будет» и реализованные в системе до этого, конечно же, согласованные управляющим комитетом проекта) влегкую могут стать и основой для должностных инструкций рядовых исполнителей и основой для всяческих регламентов и положений. А уж если туда прописать ещё и время на выполнение операций… Уууух что бы было. Но где-то не хватило у функциональных руководителей потенций, где-то — желания. То есть процессы есть, смоделированы, реализованы, на практике с небольшими отклонениями используются, но утверждать бизнес-процессы как регламентирующие документы не стали. От бумажных неподробных должностных инструкций не отказались.
Либо они запустятся (возможно, с применением кнута и пряника) либо они не оптимальны совсем. Вероятность того, что на этапе моделирования будут описаны как надо все 100% процессов — практически нулевая. Это верно. Но скелет должен быть правилен, реален, исполним. Все остальные процессы должны встраиваться в существующую систему.
Вообще, конечно, бизнес-процессы — вещь живая на предприятии и грешно думать, что вот мы сейчас один раз потщательнее смоделируем все и потом 10 лет ничего трогать не будем. Нет, как только ты закончил оптимизировать 1 процесс, ты увидел ещё 3, которые срочно надо оптимизировать. Такова ля ви…
Критерий один: ценность операции и выход из бизнес-процесса.
1. Сотрудник1 производит обсчет премии на калькуляторе, прежде чем завести в систему. Это недостаток системы. У сотрудника1 выход из операции есть — документ, но его формирование можно оптимизировать.
2. Сотрудник2 просто перепроверяет сотрудника1. Ценности никакой не приносит, если бы система не позволяла менять данные. И значимого выхода из его операции нет.
Бумажка за подписью руководителя — это тоже атавизм, следствие недоверия данным в системе. В бизнес-процессе «как будет» этой бумажки и сотрудника2 быть не должно. Корректность данных — ответственность сотрудника1. Если человек бестолочь — надо его менять, а не нанимать контролера за ним.
3. Сотрудник3 проверяет данные и в случае возникновения расхождений возвращает на исправление сотруднику1. Сотрудник2, который и без того был занят работой, не несущей ценности, вынужден повторить ненужную проверку сотрудника1 ещё раз.
Это тоже ненужные операции.
А в чем противоречие? Процесс рабочий, но не оптимальный. такого разве не может быть?
Пример из практики. 1-й сотрудник предприятия вносит в старую систему данные по премированию сотрудников подразделения. Печатает итоговый документ. Подписывает бумажку у руководителя. Несет его сотруднику 2. Сотрудник 2 берет этот бумажный документ, открывает этот документ в системе и глазками, по линеечке, проверяет каждую строчку. После этого ставит волшебную галочку в системе и документ закрывается для редактирования. Данные уходят в расчет зарплаты. А при расчете зарплаты сотрудник 3 проверяет данные, введенные сотрудником 1 и может вернуть уже утвержденный документ сотруднику 1 на исправление. И пошел второй цикл. Рабочий процесс? Рабочий. Оптимальный? Нет. Причины? А потому что сотрудник 2 не доверяет сотруднику 1, считает, что после того, как руководитель подписал бумажку сотрудник 1 мог внести изменения в документ в системе. Ну и почему-то старая система не давала в должный момент запрета на редактирование этого документа сотруднику 1. А сотрудник 3 проверяет корректность начисления премии. Почему не делает этого сотрудник номер 2? Потому что у него нет знаний и данных для проверки расчета. Почему сотрудник 1 не отвечает за корректность введенных им данных? Да потому что квалификация не позволяет, ошибаются часто, а система не позволяет производить этот расчет автоматически. Итого: занято 3 сотрудника, ценность процесса — практически нулевая.
И такой процесс был реализован годами.
В законе, на мой взгляд, нет никаких оснований для платной печати кодов, заказанных до 01.03 (п.49, абзац 5):
»Предоставление участникам оборота обувных товаров, осуществляющим маркировку средствами идентификации обувных товаров, введенных в оборот до 1 марта 2020 г., кодов маркировки остатков обувных товаров, необходимых для формирования средств идентификации, осуществляется оператором информационной системы мониторинга бесплатно."
Вот человек пишет:
Понятно, да, неприятно. Но есть другие пути, когда предыдущая команда реально обделалась в последний момент? Другая команда была в состоянии на начальном этапе спрайта сказать: «Нет, я это сделать не могу, передайте другой команде»? Я не знаю, возможно у меня специфика провинциального городка, но я ни разу не видел программиста, который сказал бы: «Да, я это точно сделаю, и сделаю до такого-то числа». Вернее, по одной задаче такое может быть, по продолжительной работе — нет. Как правило, при вопросе о реальных сроках исполнения программист предпочитает не отвечать, а падать в обморок.
А уж когда сроки из команды программистов вытянуты, согласованы с заказчиком, но командой просорваны, то единственный ответ ты получаешь от программистов «Ну не шмогла я, не шмогла».
Как избежать? Мониторить работу команды. Но как? Ведь мониторинг — это сложно, это избыточно и вообще незачем:
И да, взяв принцип построения речи в статье могу добавить: «Никогда не давайте манагеру реальную оценку состояния дела. Почаще ему сообщайте, что количество кода не пропорционально количеству прошедшего времени, что измерить процент выполнения работы программистом никак нельзя, любые измерители неадекваты. И помните, что у вас всегда есть вариант при срыве сроков сказать: „ну не шмогла я, не шмогла“. Манагер добрый, он поймет.
И вот тогда манагеру в срочном порядке приходится искать другую команду, которая конечно же, выскажет свое неудовольствие по прилетевшей задаче. И опять сзлобный косячный менеджер виноват!
И да! Контора, в которой работает программист, должна в попу дуть программисту, следить, чтобы он не обиделся на неточное ТЗ, на сжатые сроки, на клиента. Все это чисто манагерские проблемы, не его. Только вот надо ещё чтобы зарплата была вовремя:
Она же никак не зависит от качества кода продукта, от соблюдения сроков, от кол-ва найденных заказчиком багов… Деньги — они же из воздуха. Хоп — и взялись!
Понятно, что это вечная тема для холивара.
Наверное, я просто не умею себя организовать. Но у меня лично такая проблема.
Работодателю нафиг неинтересно на самом деле, на что Вы жили и какой у Вас был доход. Работодателю интересно почему соискатель с определенным уровнем компетенций вдруг оказался на берегу. Это могут быть как положительные факторы для работодателя, которые соискатель счел неважными, так и отрицательные.
Например, ищется сотрудник с «активной жизненной позицией». Живчик, короче. И работодатель узнает, что за эти три года пробела соискатель открыл 2 бизнеса, один прогорел, второй выжил, но стал, допустим, неинтересен. Для определенных вакансий, где требуется постоянно искать что-то новое — это плюс. А соискатель мог просто решить: «один бизнес прогорел, что о нем рассказывать? Второй бизнес скучный, зачем о нем говорить?».
Или просто соискатель занимался чем-то не по профилю вакансии, так как не нашел в свое время работы по профилю и решил об этом не говорить в резюме. А работодателю важно знать, что соискатель — не лентяй, что его трудно сбить с пути.
Или другой вариант: выясняется, что соискатель перегорел на важном проекте и на важном этапе проекта просто свалил в Тибет «искать себя» (в реальной жизни у меня так было). Работодатель может усомниться в том, нужен ли ему такой работник.
В любом случае, работодателя интересуют мотивы
ТС, видимо, считает, что хороший менеджер должен быть компетентнее компетентного программиста, админа, аналитика и любого из тех, кем менеджерит. А уж ИТ-директор должен быть мегагуру во всем и сам и сервак поднять, разобраться, почему заявка на договор идет неправильным путем согласования и что не так с хранимой процедурой в MSSQL.
Только, почему-то эти программисты, админы, которые считают манагера лишним звеном в обморок падают, когда нужно пойти к директору и защитить бюджет подразделения. А уж про звонок клиенту с целью урегулирования конфликта и говорить не приходится. Почему так, не понятно. Ведь разговор с руководством, с клиентами, со смежными отделами, формирование бюджетов, планов, контроль исполнения — такая фигня, это каждый может, любой дурак справится…
Если проект небольшой и руководитель проекта компетентен — то да. А если проект большой? Как, допустим, руководитель проекта (ИТ-директор допустим) должен указать производству согласовывать ли сменно-суточное задание со службой главного диспетчера или ограничиться контролем исполнения месячного плана? У РП в таком случае нет ни таких полномочий, ни таких функциональных знаний. Я думаю, что такие решения должны приниматься коллективно членами управляющего комитета.
Как это видится? Моделируем, допустим, процесс «как есть» на основании интервью и утвержденного регламента. Сотрудник говорит, что отправляет заключенный договор в производство для включения в план и только А уже производство при недостатке материалов формирует заявку на закупку. А регламент говорит, что заключенный договор должен сразу попадать в отдел закупок, когда ещё производство расчет потребностей не сделало. И что тогда моделировать? Оба варианта? А если расхождений сотни? Сколько версий процессов будет? Нет, фиксировать несоответствие и решать его надо сразу.
Вы про «красный цвет»? Ну да, там есть определенные сложности со сломом иерархии, но это не значит, что они неустранимы. Просто это будет несколько сложнее, чем в других случаях. Но я бы не сказал, что шансов нет
Скелет процессов, как описано выше в комментарии практически 1: основные процессы, вспомогательные, обслуживающие. Основные: продажи, закупки, производство и т.д., но только те процессы, которые напрямую отвечают за получение прибыли предприятия. Потом, когда закончили основные — идут вспомогательные: логистика, склады и т.д. Потом уже обслуживающие: ИТ, бюжетирование, казначейство, бухучет и т.д.
Это очередность обследования. дальше в каждом процесс идет разбивка на подпроцессы с формированием выходов и входов каждого из них. Важно по окончании моделирования одного процесса иметь все его входы и выходы. Т.к. при обследовании второго процесса, зависимого от первого, вы всегда сможете проконтролировать: а все ли, что производит 1 процесс нашло отражение во втором? Или наоборот, а все ли, что ждут на старте второго процесса готов дать процесс первый?
Вопрос был скорее в том, как описывать тогда, когда все вольно или невольно врут.
Тут, ИМХО, нужно смотреть на уровень корпоративной культуры предприятия. Если она демократичная, то просто выносить все найденные несоответствия на руководителя функционального блока и коллективно обсуждать их.
Если культура административно-приказная — готовить протокол обследования, формализовывать разрывы, делать по каждому разрыву фикс решения. Я только не очень понял чем рассказ в комментарии выше отличается от фактической деятельности. Есть бумажный регламент. Есть рассказ ответственного сотрудника, по которому видно где есть несоответствия с формализованным документом.
В клубке не надо разбираться — запутаетесь. Нужно без особых ньюансов понять «как есть» и обсуждать «как хотелось бы». Я всегда в в предпроектном обследовании пытаюсь выстроить такой скелет:
1. Услышать как бизнес-процесс идет сейчас. От начальной операции до конечной. Если в обследовании принимает участие несколько человек, то очень важно проводить интервью структурно, а то беседа превращается быстро в обсуждение какого-либо одного наболевшего вопроса или в коллективный плач Ярославны с жалобами на начальство или другие подразделения.
2. После описания «как есть» укрупненно рассказать как это реализовано в предлагаемой системе сейчас. И вывести народ на разговор типа: «О! Круто! Нам как раз так надо» или «Не, это нам не подойдет, потому что...». И всегда добиваться, чтобы это «потому что» прозвучало.
3. Перечень озвученных «потому что» уже и есть перечень насущных проблем. Дополнить его ответами на вопрос «а что бы Вам ещё хотелось видеть в системе» — и вот они укрупненные требования к автоматизации.
С проектным обследованием примерно так же, но детализация процесса и разговор намного глубже.
Вы правы и неправы одновременно. Если заказчик из первой группы, то Вы же сами говорите, что он наймет кого-то на изменение бизнес-процессов. Но что такое изменение? Это как раз моделирование, их реализация и аудит процесса в эксплуатации. А какая в современном мире реализация бизнес-процессов может обойтись без автоматизации? Вот я как раз об этом и говорил: интегратор может взять на себя функцию моделирования, если у заказчика своих потенций нет. Ну и уж точно берет на себя функцию реализации и, частично, последующего аудита.
Что касается большинства. Я уже про это писал выше: если принести все заказчику «на блюдечке», то принести ему в таком случае можно разве что «чемодан без ручки». Это та ситуация, когда заказчик говорит: «не знаю как, но сделайте мне красиво» и если интегратор на такой заказ соглашается, то берет на себя все охрененные риски того, что невовлеченный заказчик получит в итоге результат его устраивающий и применимый в его бизнесе.
Как избежать комплекса вины у заказчика? Нет никаких инструментов кроме одного: всяческими доступными средствами держать заказчика вовлеченным в проект все 100% времени жизни проекта. 100% вовлеченным. Я понимаю, что это про то, что «лучше быть здоровым и богатым, чем бедным и больным», но иначе никак.
Вообще, конечно, бизнес-процессы — вещь живая на предприятии и грешно думать, что вот мы сейчас один раз потщательнее смоделируем все и потом 10 лет ничего трогать не будем. Нет, как только ты закончил оптимизировать 1 процесс, ты увидел ещё 3, которые срочно надо оптимизировать. Такова ля ви…
1. Сотрудник1 производит обсчет премии на калькуляторе, прежде чем завести в систему. Это недостаток системы. У сотрудника1 выход из операции есть — документ, но его формирование можно оптимизировать.
2. Сотрудник2 просто перепроверяет сотрудника1. Ценности никакой не приносит, если бы система не позволяла менять данные. И значимого выхода из его операции нет.
Бумажка за подписью руководителя — это тоже атавизм, следствие недоверия данным в системе. В бизнес-процессе «как будет» этой бумажки и сотрудника2 быть не должно. Корректность данных — ответственность сотрудника1. Если человек бестолочь — надо его менять, а не нанимать контролера за ним.
3. Сотрудник3 проверяет данные и в случае возникновения расхождений возвращает на исправление сотруднику1. Сотрудник2, который и без того был занят работой, не несущей ценности, вынужден повторить ненужную проверку сотрудника1 ещё раз.
Это тоже ненужные операции.
Пример из практики. 1-й сотрудник предприятия вносит в старую систему данные по премированию сотрудников подразделения. Печатает итоговый документ. Подписывает бумажку у руководителя. Несет его сотруднику 2. Сотрудник 2 берет этот бумажный документ, открывает этот документ в системе и глазками, по линеечке, проверяет каждую строчку. После этого ставит волшебную галочку в системе и документ закрывается для редактирования. Данные уходят в расчет зарплаты. А при расчете зарплаты сотрудник 3 проверяет данные, введенные сотрудником 1 и может вернуть уже утвержденный документ сотруднику 1 на исправление. И пошел второй цикл. Рабочий процесс? Рабочий. Оптимальный? Нет. Причины? А потому что сотрудник 2 не доверяет сотруднику 1, считает, что после того, как руководитель подписал бумажку сотрудник 1 мог внести изменения в документ в системе. Ну и почему-то старая система не давала в должный момент запрета на редактирование этого документа сотруднику 1. А сотрудник 3 проверяет корректность начисления премии. Почему не делает этого сотрудник номер 2? Потому что у него нет знаний и данных для проверки расчета. Почему сотрудник 1 не отвечает за корректность введенных им данных? Да потому что квалификация не позволяет, ошибаются часто, а система не позволяет производить этот расчет автоматически. Итого: занято 3 сотрудника, ценность процесса — практически нулевая.
И такой процесс был реализован годами.