Тему этого поста подкинула переписка, которая неспешно ведется между мной и моим знакомым на тему внедрения одной вполне конкретной системы. Тему ее можно сформулировать так: что лучше - постепенное внедрение ERP шаг за шагом (модуль за модулем) или "шоковое внедрение" - то есть все и сразу?

Итак, априори есть две стратегии внедрения:

1. Можно внедрить быстро, и максимум возможного.

Последствия:

• у персонала будет только один шок
• объяснять функциональность придется дольше (ее больше)
• вероятно большее число косяков на единицу времени
• больше вероятность все запутать и провалить
• требует более тщательной подготовки

2. Внедрение "шаг за шагом"

Последствия:

• постепенная адаптация персонала к системе
• процесс объяснений постоянно вводимых новых фишек и функциональности растянется на месяца
• косяки будут вылезать постепенно (а внедренцам со стороны заказчика и пользователю будет казаться, что система просто состоит из них)
• меньше вероятность все запутать
• в любой момент можно сказать: "Стоп, нам этого достаточно"

Первый вариант мне нравится тем, что меньше риска растянуть проект, превратив его в классический долгострой. Персонал привыкнет (внедрение любой системы - ломка), а некоторая экономия времени людей налицо.

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

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

Хотя не исключены и исключения.

Кросспост из моего ИТшного блога на ITBlogs.ru

На выходных заходил на почту. Отправить перевод за детские книги в издательство. Оказалось, что на ту сумму, что указана на бумажке, почта "накручивает" сбор за пересылку. Все вроде как честно, если бы не несколько "но": я так платил в первый раз, и, разумеется, на предложение отдать больше денег ответил просьбой об обосновании без повышения тона:) (а сотрудница почты "заводилась" с полоборота - на любой вопрос клиента отвечала так, чтобы было понятно - Хозяин тут один. Она). Что удивительно - отреагировала, и объяснила, спокойно - что, и почему.

Вообще, отделение у нас "под стать": то есть, как было 60ых годов прошлого века (по интерьеру), так и осталось...

Второй случай - попытка оплатить ж/д билеты через Интернет зарплатой карточкой Visa Electron.Отказ в трнзакции со стороны банка, звонок в службу поддержки (банк - Сбербанк), приятный голос автоинформатора... расслабляющее сообщение о том, что "все разговоры записываются" и ... хамоватый оператор, суть сообщения котрого сводилась к тому, что сначала заведите себе Visa Classic, а потом уже платите через Интернет.

Мораль проста: мы на самом деле еще переживаем "осколки СССР". Если не все мы, то по крайней мере очень многие из тех, кто рождены в этом государстве до 60-70х годов. С соответствующим отношением, пониманием, "понтами" и "понятиями". И сделать с этим наверное ничего нельзя. Разве что попытаться не обращать внимания. Принимая во внимание то, что приходит новое поколение, лишенное "налета СССРности", и есть надежда на то, что ситуация может и исправится. Соврешенно случайно, вдруг - как говорил Винни-Пух.

В тему недавним рассуждениям коллег (Тенцера и Марианны).

Вопрос: как принимаются решения при выборе ПО (имеется в виду в первую очередь "тяжелые" бизнес-приложения)? С одной стороны, ответ однозначен: решения должны приниматься на основании взвешенного анализа заранее сформированных критериев. С другой - покажите мне место, где они так принимаются.

На самом деле, решения могут быть приняты двумя путями:

• самостоятельно
• при помощи внешних консультантов

Второй пункт должен эксплуатироваться весьма осторожно, так как консультанты почти всегда "под подозрением", и не без оснований, к сожалению (об этом было сказано довольно много). Тем более, что решение все равно всегда - за представителями компании. То есть за первым пунктом.

Попытаемся рассмотреть его более пристально. На решение о выборе того или иного ПО могут повлиять причины следующего характера:

• объективная оценка (относительно объективная, на основании взвешенного анализа... - см.выше)
• политические причины (могут быть самые разные. Основная - "стоит у дружественной/братской компании, стоит в холдинге". Как вариант - "акционеры/директора/управляющие разработчиков связаны с нашими акционерами/директорами/управляющими".)
• личностная (субъективная) оценка. (оценивает тот или иной менеджер с тем или иным уровнем профессионализма, соответственно, решения варьируются от "мне нравиццо, надо брать" до "стоит брать, потому что архитектура (обоснование) и функциональность (обоснование) нас вполне устраивают")

Вопрос - учитываются ли рекомендации рядовых специалистов при выборе того или иного ПО? Варианты ответа:

• иногда да (действительно, иногда прислушиваются к специалистам. Весь вопрос в том, что они должны быть действительно СПЕЦИАЛИСТАМИ, а не подмастерьями)
• а оно надо? (как вариант. Часто жизнь складывается так, что мнения рядовых специалистов топов не интересует - сказано поставить и внедрить, извольте исполнять!)
• специалисты должны дать базис для принятия решения (это лично мне ближе; так как учитывается и опыт "снизу", и требования "сверху")

Что еще? Если делать по-умному, то перед тем как выбирать, надо попробовать. В идеале - сделать тестовый запуск на ограниченном числе автоматизируемых процессов (один-два). И поковырять систему недельку-другую. Хорошо? - Да. Но накладно, и требует установки системы, не говоря уже о том, что банально нужны договоренности с разработчиками/поставщиками ПО и люди - тестеры. Тем не менее - весьма любимый мной вариант. Вероятность "обжечься" резко падает по сравнению с "котом в мешке".

Еще один интересный момент. Предположим, есть 10 (а лучше, как в анекдоте - 20) систем, автоматизирующих область Х. Нужно выбрать одну. Что делаем? Классика жанра состоит в том, что строим классическое (простите за тавтологию) сито:

1. Формируем требования (а куда же без них, в конце концов надо представлять, что хочет бизнес-заказчик)
2. Формируем критерии отбора
3. Отбираем пару-тройку лидеров (самый интересный момент, о нем как раз я подробно написал выше)
4. Разворачиваем их
5. Тестируем (имитируем работу пользователей, возможно - с некоторыми допущениями)
6. Делаем орг.выводы
7. Принимаем решение (тоже см.выше).
8. Подписываем договор, и на внедрение (совсем отдельная песня).

Как оно бывает на самом деле - не мне вам рассказывать:) Вопрос - часто ли срабатывает подобная классика? К сожалению, практически никогда. Почему? Да потому, что:

• цели внедрения запросто могут быть не определены;
• требования к продукту существуют в 3..4 головах, причем - разные;
• критерии отбора сформировать невозможно, т.к. непонятно, что выбираем;
• понимания, какие системы можно рекомендовать - нет, так как все равно выберут за нас;

Тогда последний вопрос: как жить дальше? Да так: исправлять ситуацию, где возможно, где можно - помогать выбору, где нельзя - подстраиваться и выжимать максимум бизнес-перспектив из поставляемого ПО. В общем, жить полной жизнью и не скучать:)

Кросспост из моего ИТшного блога на ITBlogs.ru

Не думай о секундах свысока... натолкнулся на замечательный пост о том, как надо и как не надо давать поручения. На ITBlogs он прекрасно пошел как дополнение к моему посту "В пользу бедных", а здесь, ввиду того, что комментарии для ITBlogs постов закрыты, решил привести прямую ссылку: Принцип ПВО. Ситуация, описанная в посте, довольно жизненная, но могут быть вариации, в частности, "важные поручения" могут быть выданы не только письменно (по email, в бумажном виде), но и устно, при личной встрече, или вообще - через "третьи руки" (самый интересный случай, когда кто-то просит кого-то озадачить кого-то еще, на эту тему я вроде как уже писал)...

Грустно как-то. Неужели так - ВЕЗДЕ?

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

ПО довольно простое: позволяет формально ставить задачи (раздавать поручения) по "горизонтали" и "вертикали"). Организуется это в виде описания задачи и ленты действий, куда все участники процесса пишут свои комментарии. Права на постановку задач выдаются по умолчанию в соответствии с иерархией (орг.структурой), либо особо (персонально), на основании заявки (соответствующим образом утвержденной). Вроде бы, автоматически следует, что такой механизм раздачи прав гарантирует исполнение поручений, поставленных в соответствии с этими правами. Так вот, основная проблема, с которой мы столкнулись в процессе внедрения и эксплуатации ПО, состоит в том, что некоторые сотрудники считают что то, что написано в ленте действий, есть призыв к безусловному и немедленному выполнению, а некоторые, наоборот, просят регулирующий документ, в котором было бы установлено, на основании чего задача, поставленная в системе, должна быть принята к реализации. (Приказ о вводе системы в эксплуатацию не в счет - в нем определено, что система вводится в эксплуатацию, но не определено, что именно является фактом начала действия для каждой задачи).

Итог таков: требуется регламентирующий (регулирующий) документ, в котором будет отражено - что нужно принимать к исполнению, что - не нужно, на что реагировать, и что - писать в ленту действий. А подумал я вот о чем: расширяя, можно сказать, что практически любая сколько-нибудь сложная система требует регламента, поскольку, даже если она настроена идеально, и из нее можно однозначно понять - "куда бежать, и что делать", всегда остается пресловутый "человеческий фактор", который говорит о том, что все равно кто-то что-то поймет, или найдется тот, кто пойдет по пути сознательного саботирования, или... (см. замечательный пост Анатолия Тенцера - "корпоративное айкидо"). Причем, абстрагируясь от конкретно "нашей" системы, есть ощущение того, что даже простейшие вещи - такие, как корпоративный информационный сайт - должны иметь свой регламент наполнения и работы. Но при этом есть вторая сторона медали - риск превратиться в неповоротливую бюрократическую контору просоветского типа.

В общем, жизнь - это вечный поиск компромисса. Во всем.

Кросспост из моего ИТшного блога на ITBlogs.ru

Не могу удержаться... На ITBlogs последний пост Анатолия Тенцера - "Корпоративное айкидо". Рекомендуется к прочтению всем! Особенно - ИТшникам, менеджерам проектов, а также - ТОП менеджерам. Изумительной точности вещь, описывающая тонкости управления проектами. ;)

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

Итак, история (с)А.Молль:

Капитан - адъютанту: «Как вы знаете, завтра произойдет солнечное затмение, это бывает не каждый день. Соберите личный состав в 5 часов на плацу, в походной одежде. Они смогут наблюдать это явление, а я дам им необходимые объяснения. Если будет идти дождь, то наблюдать будет нечего, в таком случае оставьте людей в казарме».

Адъютант – сержанту: «По приказу капитана завтра утром произойдет солнечное затмение в походной одежде. Капитал на плацу даст необходимые объяснения, а это бывает не каждый день. Если будет идти дождь, наблюдать будет нечего, тогда явление состоится в казарме».

Сержант – капралу: «По приказу капитана завтра утром в 5 часов затмение на плацу людей в походной одежде. Капитан даст необходимые объяснения на счет этого явления, если будет дождливо, что бывает не каждый день».

Капрал – солдатам: «Завтра в самую рань, в 5 часов, солнце на плацу произведет затмение капитана в казарме. Если будет дождливо, то это редкое явление состоится в походной одежде, а это бывает не каждый день».

Солдат - солдату: «Завтра в самую рань, по приказу капитана, в 5 часов, состоится затмение капрала на плацу в походной одежде. Если будет дождливо, то капитан даст объяснение этому явлению в казарме, что бывает не каждый день».

Забавно? Ага! А теперь - как это бывает «у нас» (в ИТ, то есть).

Совет директоров - секретарю: «Как вы знаете, современные тенденции рынка таковы, что без системы, управляющей отношением с клиентами, то есть CRM, не обходится ни одна серьезная команда. Мы работаем над этим, поэтому завтра, в 11-00, в зале для переговоров состоится собрание заинтересованных лиц, на котором будет объявлено о запуске проекта и объявлены участники команды. Перед сотрудниками выступит президент. Поэтому, если он не вернется из командировки, собрания не будет, а о времени будет сообщено дополнительно. Кстати, надо дать задание в финансовый департамент сформировать бюджет, для чего попросить помочь ИТ департамент».

Секретарь – директору финансового департамента: «По решению совета директоров, современные тенденции рынка изменились. Поэтому мы будем проводить установку CRM и работать над этим завтра, в командировке, после выступления президента в переговорной зале. Вам необходимо подсчитать и обосновать, почему и сколько это стоит, но только если собрания не будет, в противном случае будут объявлены участники команды и повышены клиенты, с участием ИТ департамента».

Директор финансового департамента – менеджеру: «По приказу президента компании, началась командировка наших клиентов в ИТ департамент, поэтому выступит совет директоров, который произведет установку CRM. Мы должны проанализировать возможные затраты в случае проведения указанного мероприятия в переговорной зале».

Менеджер – сотрудникам: «Завтра, после выступления совета директоров, президент нашей компании даст комментарии относительно стоимости установки CRM в переговорной зале, чтобы дать клиентам департамента ИТ возможные затраты. Мы должны проанализировать это».

Специалист фин.департамента - ИТ-специалисту (в курилке): «Завтра в переговорной зале, президент ИТ департамента даст клиентам по CRM, чтобы установить возможные затраты. Вы должны помочь».

...вроде бы - не смешно.

Оригинал и комментарии: ITBlogs.ru