Pull to refresh

Comments 20

Хорошо, хоть есть такие люди… Но интеграторы часто зарабатывают деньги только потому, что не сильно сопротивляются подходу заказчика — вы нам внедрите эту систему, а уж зачем мы сами разберёмся, при этом бизнес-процессы заказчика не меняются абсолютно.

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

Кстати, со стороны заказчика, хочу обратить внимание на серьёзное упущение со стороны интеграторов, следующих подходу «пришёл-сделал-ушёл» — ещё в начале внедрения системы должен быть явно проработаны последние два важных этапа Поддержка и Развитие.
Без них -система постепенно деградирует и цели в долгосрочной перспективе достигнуты не будут.

В этом плане очень показателен подход Кайдзен vs Инновации

image
Еще в стадии записать Смерть(она же вывод из эксплуатации).
А по развитию — хорошо себя чувствует тот, чья система успевает за его потребностями(ну отстает по минимуму). Жизнь меняется значительно быстрее, чем кажется. Но, к сожалению, некоторые «покупатели» видят софт как «купил и забыл».
А еще «Поддержка? — Сами разберемся!», «Доработки — Почему так дорого, четверть стоимости коробки за небольшой модуль!». Тут я больше о коробочном софте для малого бизнеса.
PS А графики честно не понял =)
По поводу вывода их эксплуатации — да, согласен, это тоже часто вопрос.
Развитие — целиком и полностью согласен — и именно поэтому я и привёл графики с Кайдзен, т.к. этот подход как раз и пропагандирует постоянное улучшение.
Подробнее ( в т.ч. и про графики =) ) — Масааки Имаи — Кайдзен: Ключ к успеху японских компаний. Глава 2 — Совершенствовании на Востоке и Западе.

Для меня вывод из эксплуатации как правило означает: клиент переходит с чего то на наш софт, необходимо вытащить оттуда все полезное. И вот некоторые производители софта подумали об этом и дали как минимум экспорт с минимальной гибкостью. А у некоторых все не очень.
Хотя вопрос конечно шире.
PS А про кайдзен я в курсе, графики для неподготовленного человека туманно идентичны (не подписаны оси, немного разный масштаб, чуть тут, чуть там). Без расшифровки не прокатит.
Если «инновации» — это новшества привносимые в систему для ее улучшения, а «кайдзен» — это постоянные улучшения системы, — то напрашивается вывод что «инновации» это составная часть «кайдзен», верно?!
Это уже казуистика =)

И если я правильно понимаю понимаю изначальный посыл Кайдзен, то кайдзен — это эволюция, а инновации — это революция.
И идеальным вариантом является сочетание обоих подходов.
«Без казуистики и не туда и не сюда», если заранее не договариваться об определениях, как «дедушка Бекон советовал». А также без привязки к реально существующему объекту изменений, который известен обоим сторонам диалога в одинаковой мере хорошо.

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

Принципы самих подходов несовместимы, но методы и инструменты могут одинаковые применяться как при «кайдзен»-ориентированном подходе, так и при «инновационно»-ориентированном. На картинке с графиками мы наблюдаем не «Кайдзен» vs «Инновации», но «Инновации» vs «Инновации + Кайдзен». Собственно из-за этого и вопрос то был: «Кайдзен» == «Инновации + Кайдзен» или нет?!

Важен ваш взгляд на данный вопрос и ваше мнение, а казуистику можно смело в топку. С уважением, Артур
Прошу прощения что влезу в Вашу беседу. Чем Кайдзен отличается от обычной доработки, усовершенствования?
«кайдзены» со стороны ваших заказчиков — это изменения и настройка их процессов (от заказа до исполнения) иногда они не требует изменений со стороны IT систем, а иногда требует. Будут ли новые требования серьезными или нет вопрос каждого конкретного случая в отдельности.

«кайдзены» для вашей компании очень трудный пример, т.к. в IT компаниях наверное проектные принципы работ, с которыми системный подход к улучшению процессов может быть связан очень специфически. Вопрос очень интересный, но ответа удовлетворительного у меня нет.
Просто не понимаю зачем использовать термины типа «Кайдзен» — ведь можно сказать по простому. В прочем предположение есть усовершенствование будет явно дешевле чем «Кайдзен» — получается то это всего лишь маркетинговый ход, не имеющий к действительности отношения. Например если я работаю молотком у него не удобная ручка, я ее сделаю для себя удобнее и на этом дело заканчивается. Но можно собрать несколько проектных групп, назначить в каждую менеджера, назвать импортным словом, то в итоге получим всю туже усовершенствованную ручку, зато с виду какое большое дело сделали и как красиво рассказали.
этот случай когда человеческая речь является языком «программирования» с многоуровневой абстракцией, или другими словами понимание данного термина у 10 разных человек может и будет разным, а в дословном переводе всего лишь: изменения к лучшему. Но правильное понимание данного слова как айсберг, всего самого основного смысла в нем заложенного по самому слову не видно. Считайте его ссылкой на базовую концепцию, знание которой подразумевается как само собой разумеющееся в диалоге.

Описываемый вами случай подходит к ситуации когда начальник говорит подчиненному: внедри мне систему, а подчиненный либо не знает либо боится сказать что эта систему должен сам начальник применить на своем уровне полномочий к своим принципам работы, а молоток тут и не причем.
Мой взгляд — что самое разумное, при внедрении любой системы ( ИТ-продукт, бизнес-система или любой другой инновационной ( новой)) кроме её внедрения всегда надо помнить про то, что будет после внедрения и не забывать про постоянные улучшения ( тот же цикл Деминга PDCA — суть то же самое)

Т.е. правильный подход: Разумное развитие = «Успешное внедрение + постоянное улучшение»
Вот случай устроился так недавно на промышленное предприятие, а там такое: реальные попытки внедрения более 2 лет (следы первых попыток уходят аж в 2009 год) + регулярный аудит (1-2 раза в год) + чудная методика вышестоящей компании + фрагментарно-поэтапный подход к достижению критериев = сильно удручающая картина; примерно также как тут https://habrahabr.ru/post/308024/#comment_9763332 только ручки (внедряемой системы) до сих пор как не было так и нет.

Вот сижу теперь и думаю, как из руин замок построить, точнее фундамент в порядок привести… с одного края водопад размывает, с другого обрыв, а вокруг безлюдная пустыня с редкими оазисами.
Я бы начал с попыток собрать всё, что необходимо сделать и расставил бы приоритеты задач/проектов по следующей схеме:
Сначала объединение задач/проектов в группы
  • 100-е — важно, срочно и критично для бизнеса
  • 200-е — важно, нужно, но критично будет только в дальнейшем
  • 300-е — уже не так важно, можно думать и т.д.


А потом уже в группе 100-х и 200-х делил бы на группы поменьше 110-е, 120-е и т.д. и далее
При этом руководствуясь правилами — чем меньше приоритет, тем раньше надо делать ( т.е. 101 важнее 121 ) и никогда не повторяя приоритеты.
После этого заниматься 101-м приоритетом, затем 102 и т.д. или сразу группой ( если есть возможность), оставляя в фокусе не более 5-10 задач/проектов.

При этом регулярно проводя переоценку приоритетов и делая минимальные активности по всему, что вне моего фокуса
Найдите реального хозяина, того кто может проявить волю и поставить задачу. На крайний случай менеджера с достаточным административным ресурсом, который хочет заработать (бонусы, продвижение в карьере, и тд.) при успешном внедрении системы и определитесь с ним в целях и рисках. Без этого все умные методики уйдут в мусор и затраты для предприятия.
Неистово подтверждаю и соглашаюсь.
В своём ответе я об этом не упомянул, считая само собой разумеющимся
Кстати, со стороны заказчика, хочу обратить внимание на серьёзное упущение со стороны интеграторов, следующих подходу «пришёл-сделал-ушёл» — ещё в начале внедрения системы должен быть явно проработаны последние два важных этапа Поддержка и Развитие.
Без них -система постепенно деградирует и цели в долгосрочной перспективе достигнуты не будут.

100% так. Нужно будет дополнить статью или написать другую «Поддержка и развитие» это важная тема тема.
Это зависит от кол-ва внедрений. Если у одного заказчика всё работает (поддерживается) и развивается, а у другого всё где то застряло непонятно на каком из этапов — тут явны видны проблемы в парадигмах управления. Помогать заказчикам конечно можно и нужно, не бесплатно конечно тоже (есть ведь те, кто оценивает экономику сугубо по экономии), но и заказчик должен иметь твёрдое и устойчивое желание быть «лучше остальных» или хотя бы «не отставать», и должен быть готов сделать ради этого всё, а не только «купить внедрение» да ещё и «подешевле» (такой подход демонстрирует явный умысел спихнуть с себя проблемы притом с больной головы на здоровую).

Тема «Поддержки и развития» также тождественна теме «активности» проекта внедрения. Если он активен — его поддерживают и развивают, если нет — то поддерживать и развивать просто нечего и некуда.

И… Если к Вам пришёл «интегратор» только чтобы «внедрить и уйти» — грош цена такому интегратору, и возможно зря Вы к нему обращались…
Хотя возможен и вариант при котором интегратор «берёт паузу», для достаточно глубокого самостоятельно изучения системы (и всех её возможностей) Вашими сотрудниками (далеко не всегда считающими что нужно что то изучать и чему то учиться, в т.ч. работать по-новому = более эффективней).
Естественно если проект успешен, то будет интерес и к его сопровождению и развитию. А вот «интеграторов» почему то не люблю. Как правило все закачивается желанием впарить sap с «лучшими» бизнес практиками. А если sap не обладает нужным функционалом, то это процессы сделаны не правильно :)
Sign up to leave a comment.

Articles