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

Итак, получается первый важный вывод: информационная система вторична по отношению к процессу.

Второй вывод, так или иначе следующий из первого - каждая система сильна в какой-либо одной (или нескольких) предметных областях. В этом смысле интересно рассмотреть ту самую пресловутую 1С - она до сих пор воспринимается как "бухгалтерская" система (но, сказать по правде, она, по сути не являясь уже чисто "бухгалтерией" несет в себе много рудиментов того времени). Или, например, HP Service Manager - ее воспринимают как "очень навороченный helpdesk". Хотя из обоих систем можно сделать все, что угодно: от склада до учета осколков метеорита. Весь вопрос только в том, что для решения конкретной задачи лучше и правильнее использовать ту систему, которая содержит в себе наметки на решение этой задачи. Или инструменты ее решения.

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

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

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

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

PS Давно не писал про ИТ. С момента, как перестал активно жить ITBlogs - соскучился по теме. Так что наверное в ближайшее время еще попишу об этом.

Я тут писал про то, как слетал в Краснодар. Примерно то же самое я отправил а авиакомпанию Россия по электронной почте (в части которая касается инцидента в аэропорту). Я не ругался - просто изложил "ситуацию глазами пассажира".

31ого мая пришел ответ: скан официального письма с разъяснением. В общем, ничего нового: аэропорт Краснодара не обеспечил воздушное судно устройством принудительного запуска двигателей. И извинения.

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

PS Кстати, общее время задержки - 13 часов с какими-то минутками.

Давно я не писал ничего на ITBlogs. Исправляюсь....

Итак, из разряда "мысли вслух".

Обнаружил (умозрительно) парадокс. Заключается он в том, что чем меньше проект, тем более тщательное и конкретное ТЗ на него должно быть написано.

Доказательство: по ТЗ оценивается объем работ, который необходимо проделать, и, на основе этого объема - дается бюджетная оценка проекта (это допущение, так как все знают, что в 50% случаев бюджет возникает до ТЗ.. такой случай тут не рассматриваем). В бюджет обязательно закладываем риски. Маленький проект - это маленький бюджет. Маленький бюджет - небольшой бюджет на риски. Так как система сдается по ТЗ, то наличие обтекаемых и нечетких формулировок - это зона потенциального действия рискового бюджета. Который, как известно (см. выше) в небольших проектах невелик (а некоторых отсутствует совсем). То есть, наличие в ТЗ на маленький проект четких формулировок - явно снижает риски (не скажу, что всегда до уровня, который закладывается в бюджет, но снижает).

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

Если же вспомнить, что обычно (в правильных случаях - больших проектов) за ТЗ идет ТП, где описывается - КАК сделать все то, что описано в ТЗ, то вроде как возникает еще один повод расслабиться и вздохнуть с облегчением: уж в ТП-то будет описано все, до пресловутого "последнего винтика". Как бы ни так! В самом лучшем случае там будет описано процентов 70 того, КАК надо сделать описанное в ТЗ. 30% - на риски. Суровая правда жизни :)

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

Вот как-то так мыслится :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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