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

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

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

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

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

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

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

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

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

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

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

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

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

В дискуссии у Влада (Семь (восемь?) аргументов к покупке SAP) SAP (кажется, с подачи Андрея Колесова) начали сравнивать с отечественной 1С. Вот я и подумал: а почему бы в аналогичном ключе не попытаться понять, почему люди берут 1С?

Начнем с того, 1С бывает разная. "Бухгалтерию" и "ЗУП" ("зарплата и управление персоналом" переводится) берут почти все - от мала до велика. Причина - бухгалтерию надо в чем-то вести, А 1С - дешев, неприхотлив и (что немаловажно) - довольно регулярно обновляется (бывают и "лажи" - это когда обновление приносит с собой больше суматохи, чем пользы, особенно - на модифицированных конфигурациях. Но это совсем другая история). так вот, обновления несут в себе в том числе обновления форм документов - что в условиях, когда они (формы документов) постоянно меняются, немаловажно.

Дальше, 1С - система, относительно легко и дешево настраиваемая на собственные задачи. Действительно, в настоящее время сформировалась целая индустрия фирм-партнеров 1С и специалистов-одиночек, которые могут сделать из системы все, что угодно - например, написать склад на базе бухгалтерии (большого смысла в этом нет - но технически возможность есть).

1С - система, которую вы приобретаете столько сколько нужно. То есть лицензии вы всегда можете докупить, более того, всегда (безболезненно - ???) можете перейти от локальной версии к версии SQL. Разумеется, заплатив.

1С обладает множеством конфигураций. И сама компания 1С, и ее партнеры написали для 1С массу конфигураций - от управления автохозяйством и складом до управленческого учета рабочего времени супервизоров. Одно управление предприятием чего стоит.

1С не навязывает свои процессы. Она готова подстроиться под существующие. Как обычно, без гарантии корректности обновлений, и вообще по возможности без гарантий. Но партнеры, как правило, обладают "волшебной отмычкой", то есть могут накатить обновления и на нестандартную конфигурацию. А также дать соответствующие гарантии. Разумеется, не безвозмездно.

1С открыта для разработчика. Язык разработки, правда, для меня лично - эзопов, но посмотреть как сделано что-то, в большинстве случаев можно. Также, как и разработать что-то свое. "Сбоку" или "сверху", а также "внутри" существующей конфигурации. Или вообще написать свою конфигурацию.

К минусам можно отнести то, что обычно 1С привыкли считать сугубо "бухгалтерской" программой, что до сих пор заметно - даже в том же УП (которое, насколько я понял, 1С считает своим "флагманом").

Также минусом принято считать "несерьезность" 1С. С моей точки зрения - пережиток прошлого. Безусловно, проблемы с системой есть (а покажите мне, где их нет!) - но в целом система достаточно "взрослая".

Минусом является также то, что "индустрия 1С" неизбежно породила и халтурщиков - то есть тех, кто не зная системы, лезет в боевую разработку, вместо того, чтобы подучиться. Это, кстати, неизбежное зло - практически для любой популярной системы.

Общие - мои личные впечатления таковы: 1С - конструктор. С хорошим набором деталей и несколькими готовыми собранными из них предметами. И если нет серьезных (а также - политических или религиозных) аргументов в пользу других систем, то брать вполне можно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С маленькими узкоспециализированными проектами все более или менее понятно: существуют целые индустрии по производству сайтов, типовым и не очень решениям на базе 1С и т.д. С большими ситуация тоже более или менее ясна: делать проект, например, по вещанию IP TV оператору связи, который не имел до этого подобного опыта быстрее, надежнее и (скорее всего) дешевле силами аутсорсинговых специалистов/компаний (отдельный больной вопрос аутсорсинга - качество оставим "вне области рассмотрения"). Но жизнь не стоит на месте, и аутсорсинг постепенно пришел в сферу средних и малых проектов. Когда-то давно я сформулировал для себя причины, в силу которых принимается решение об аутсорсинге:

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

Больше причин для аутсорсинга мне сформулировать довольно сложно. Таким образом, получается, что в мире появилась тенденция к удешевлению решений, в том числе аутсорсинговых, а корпоративный потребитель "созрел" для того, чтобы передавать хотя бы часть своих задач внешним исполнителям. Или я что-то упустил?

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