|
|
www.it4business.ru
|
Читайте не торопясь
Приветствуем!
Если вы здесь впервые, то вы уже нашли место, где растут и развиваются IT-менеджеры.
www.it4business.ru — портал для IT-менеджеров, для тех кто руководит, принимает решения и отвечает за результат. Темы портала: Карьера, Персонал, Технологии.
Можно подписаться на RSS портала и всегда быть в курсе, что нового мы тут делаем. Спасибо и заходите еще!
Дата публикации: Октябрь 15, 2009 в 1:46 am.
Темы: Библиотека, 2009, Разработка ПО, Управление процессами, Управление рисками
Распечатать
Традиционно считается, что свой пик популярности «домашние разработки» пережили в 90-е годы. Во-первых, в те времена становился рынок услуг по системной интеграции. Во-вторых, отсутствовал какой бы то ни было рынок специализированного программного обеспечения. В-третьих, различные компании отличались многообразием и «неповторимостью» своих бизнес-процесов. И, наконец, в-четвертых, рынок IT-специалистов был еще не развит. Постепенно рынок рос, росла квалификация IT-специалистов, появлялись новые системные интеграторы, и количество домашних разработок все уменьшалось и уменьшалось.
Впрочем, Интернет-проекты и направления бизнеса, в которых потребителям предлагают действительно уникальные услуги, требующие уникальных IT-решений, все это время успешно накапливали опыт InHouse разработок. Но все же решающим фактором для работы «на дому» стал мировой финансовый кризис, дошедший и до России. И пока всезнающие аналитики и экономисты строят прогнозы и спорят, достиг ли кризис дна, IT-отрасль ищет свои пути его преодоления.
Стремление к снижению внутренних расходов компании, борьба за повышение эффективности бизнес-процессов, массовые увольнения и, как следствие, наличие на рынке труда большого количества незанятых IT-специалистов, а также появление внутри компаний новых бизнес-процессов и создание новых продуктов - все это причины, из-за которых InHouse разработки снова актуальны.
Когда IT идет домой… (о ситуациях)
Итак, когда же в компании может стартовать внутренний проект по созданию какого либо информационно-технического решения?
Сценарий 1. Снижение расходов - вот то, что происходит в первую очередь. После сокращения корпоративных социальных программ и текущих расходов, на первое место выходит сокращение штатов. Теперь тот объем работы, который выполняли раньше десятки сотрудников, выполняют два-три человека. Логичнее всего в такой ситуации продемонстрировать акционерам, бизнес-подразделениям, руководству экономическую эффективность IT-подразделения и загрузить себя и своих сотрудников работой. Тем самым, естественно, постараться сохранить отдел в целости и сохранности. В кризисных условиях может стать актуальна автоматизация тех задач, которые еще недавно было проще делать руками низкоквалифицированного персонала. Могут остаться задачи, которые предполагалось выполнять силами внешних разработчиков, но на которые у компании уже нет денег.
Сценарий 2. Новые продукты. В условиях снижения нормы прибыли и изменяющейся ситуации на рынке, компания может начать создавать новые продукты и услуги, актуальные в кризисные времена. Таким продуктом может стать и Интернет-магазин, и новый сервис для заказчиков, и побочные продукты основного вида деятельности. Общим для всех них будет являться суровая необходимость организации экономически эффективного бизнес-процесса. А, как известно, именно автоматизация и призвана повышать производительность труда и экономическую эффективность. Мало вероятно, чтобы по этому сценарию развивались события в компаниях реального сектора экономики, торговли и других компаниях с относительно статичными бизнес-процессами, однако в области консалтинга такой сценарий вполне возможен.
Сценарий 3. Эмоции. В кризисных условиях множество решений принимается не на основании фактов и анализа ситуации, а на основании эмоций. Выглядеть такое эмоциональное решение может примерно так. На совещании, посвященном вопросам экономии бюджета, выясняется, что на создание On-Line магазина или сайта выделена достаточно серьезная сумма. Но фактически этих денег нет. Департамент маркетинга уверен, что без нового сайта (Интернет-магазина) компании сложно конкурировать с другими. Но денег все равно нет. И вот тогда взоры руководства направляются в сторону IT-департамента. Волевым решением ему поручается в кратчайшие сроки и без увеличения бюджета создать требуемый продукт. Безусловно, это самый печальный из возможных вариантов.
Быть или не быть? (о рисках)
Чем в условиях кризиса может быть полезна «домашняя разработка»?
Было бы честным перечислить также возможные риски «домашних разработок» и пути их минимизации.
| Риски | Методы минимизации |
| Высокая стоимость владения полученным продуктом
Сложность технической поддержки и управления изменениями |
Документирование кода
Документирование БД Документирование разработки Ведение рубежного контроля |
| Затягивание сроков сдачи продукта | Наличие утвержденной документации разработчика (функциональные требования, техническое задание)
Ведение рубежного контроля Возможность привлечения outsource и freelance - разработчиков (наличие соответствующего бюджета) |
| Низкое качество полученного продукта | Проведение приемных испытаний
Наличие плана-методики испытаний Контроль версий Документирование кода Документирование БД |
| Полное не завершение проекта | Не применение, перечисленных выше методов минимизации рисков. |
Сколько вешать? (о стоимости InHouse разработок)
Мысль о низкой стоимости InHouse разработок, пожалуй, самая спорная. Впрочем, говорить о стоимости некого абстрактного продукта в принципе бесполезно. Как и о стоимости вполне конкретного продукта - слишком много методик расчета. В большинстве случаев понятие стоимости IT-решения является одним из главных видов оружия во внутриполитических сражениях и с одинаковым успехом может применяться обеими сторонами. Как для доказательства немедленного банкротства компании после начала проекта, так и для доказательства невозможности дальнейшего существования компании без реализации проекта.
Однако в кризис от вопроса стоимости никуда не уйти, поэтому в качестве альтернативного варианта можно предложить оценивать не стоимость разработки, а экономический результат. Например, стоимость высвобожденного рабочего времени сотрудников.
Предположим оператор с заработной платой 20тыс рублей в месяц и 8 ми часовым рабочим днем тратил на внесение данных 4 часа, что в стоимостном выражении составляет ( 20000/(8*21))*4= 476 рублей в день. После создания программы автоматического ввода данные заносятся тем же оператором в течение 15 минут или стоят (20000/(8*21))*0,25 =30 рублей. Иначе говоря, написанная программа ежедневно экономит 446 рублей, что составит в год - 112 392 рубля
Сумма, приведенная в примере, конечно невелика, однако способна полностью окупить то рабочее время, которое будет потрачено на разработку. Еще один плюс - в штате компании сохраняется ценный IT-специалист.
Задача - выжить (О выборе объекта автоматизации)
Если рассматривать InHouse разработки как метод выживания IT-подразделения (при этом инициатива такой разработки полностью лежит на CIO), можно определить основные требования к выбору объекта автоматизации.
Первое. Необходимо автоматизировать только те бизнес-процессы, экономический результат автоматизации которых может быть легко оценен и наступит в краткосрочной перспективе. Как правило, это бизнес-процессы Front-line подразделений.
Хорошо - автоматизация ввода данных освобождает 80% рабочего времени оператора.
Плохо - автоматизация бронирования переговорных комнат освобождает 20% рабочего времени офис-менеджера.
Второе. Лучше всего автоматизировать уже существующий бизнес-процесс.
Третье. Нельзя добавлять новые операции в существующий бизнес-процесс.
Четвертое. Желательна возможность получения первых результатов к окончанию одного из отчетных периодов ИТ-подразделения.
Пятое. По возможности, требуемый продукт должен быть легким в создании, а его функциональная насыщенность должна быть настолько низкой, насколько это вообще возможно.
Резюмируя написанное выше, можно сказать, что наименее рискованным будет сравнительно простой, краткосрочный проект с понятным экономическим эффектом.
Хорошо - автоматизированное обновление продуктового каталога и складских остатков на Интернет-сайте, позволяющее полностью отказаться от услуг оператора.
Плохо - собственная разработка решения с функционалом CRM.
Отдельно хочется остановиться на домашних Интернет-проектах. Разработка On-line решений несет сравнительно мало дополнительных сложностей, часто рассматривается в качестве задачи для домашней разработки. Однако надо отдавать себе отчет в том, что, во-первых, любой Интернет-проект предполагает работу не только ИТ-специалистов, но и дизайнеров. Во-вторых, к сожалению, критерием оценки Интернет-сайтов очень часто является категория «нравится - не нравится», и в процессе работы над проектом зачастую необходимо делать так, чтобы «нравилось». А это определенные сложности, поскольку решение обычно принимают несколько человек, и вкус и цвет, как известно, у каждого будет свой. В-третьих, Интернет-сайт невозможен без контента - его написание зачастую создает огромные сложности.
Кто? Где? Когда? (О ресурсах)
Жизненный цикл проекта можно условно разделить на несколько стадий:
Для того чтобы принять окончательное решение о старте проекта, необходимо оценить не только планируемый экономический эффект, но и требуемые для успешного завершения проекта ресурсы. Однако прежде чем оценивать ресурсную базу, необходимо провести предпроектную подготовку. В результате которой должны быть созданы документы, описывающие автоматизируемые бизнес-процессы и функциональные требования, приложены презентационные материалы.
Описание автоматизируемого бизнес-процесса необходимо, прежде всего, для создания функциональных требований и технического задания. Важно также и то, что во время создания описаний бизнес-процессов все участники приходят к единому пониманию технологии работы и методов автоматизации, снижается вероятность выявления неучтенного функционала. Для описания бизнес-процессов удобно пользоваться методологией IDEF 0 c малой глубиной декомпозиции на ранней стадии предпроектных работ. Если продукт, создание которого планируется автоматизировать, еще отсутствует, имеет смысл спроектировать некий идеал этого бизнес-процесса. Правда, тут важно не впасть в очарование этим самым «идеалом» и вовремя осознать, что все равно работать он будет несколько по-другому.
Не следует путать функциональные требования и техническое задание. Функциональные требования должны описывать только перечень функций, которые реализует создаваемый продукт. Для каждой функции должно быть сделано краткое описание, необходимые данные, результаты выполнения функции. На самом раннем этапе работы в этот документ необходимо включить требования по интеграции с другими информационными системами. В начале создания функциональных требований удобно пользоваться технологиями ментальных карт (MindMap), а затем переходить к блоковым схемам и текстовому документу. Целесообразно начинать создание функциональных требований с документа объемом не более двух страниц и в дальнейшем его расширять.
С самого начала работы над проектом, надо быть готовым к тому, что придется множество раз рассказывать разным людям одно и то же - суть проекта. В большинстве случаев от этого рассказа будет зависить результат и форма проекта, финансирование, отказ или принятие решения о начале работ. Необходимо учитывать, что большинство людей, с которыми придется общаться, не являются профессионалами в IT-сфере, поэтому документ должен быть максимально сжат по объему (не более 3-5 страниц), в нем должны отсутствовать профессиональные IT-термины, может присутствовать небольшое количество предельно простой и понятной деловой графики.
Примерное содержание презентационных материалов может быть таким:
Хочется особо отметить необходимость отражения в предпроектной документации критериев завершения проекта. Это должно быть короткое описание ситуации, при которой проект считается успешно завершенным. В описании критериев успешности необходимо очень точно соблюсти баланс между техническими критериями и бизнес-результатом. Нельзя вносить в критерии успешности проекта те результаты, которые напрямую не зависят от деятельности IT-подразделения.
Хорошо
Плохо
В перечисленном выше перечне документов отсутствует важнейший документ -техническое задание. Это не случайно. Дело в том, что именно от качества этого документа в огромной степени зависит результат проекта. Но на стадии предпроектной подготовки фактическая потребность в таком документе отсутствует. Трудозатраты на создание качественного технического задания, как правило, очень велики, и в ситуации, когда решение о начале проекта еще не принято, экономически не целесообразны. На предпроектной стадии всех интересует вопрос «что?» - ответ на этот вопрос должен содержаться в функциональных требованиях. Вопрос «как?» возникнет только перед началом работ, и ответ на него уже должно давать техническое задание.
Когда первая часть предпроектной подготовки завершена и получено общее представление о содержании проекта, можно приступить к оценке необходимых ресурсов.
Из всего многообразия видов ресурсов хотелось бы обратить внимание на следующие:
В начале анализа доступных ресурсов необходимо оценить идеальную потребность в ресурсе, а затем фактическое наличие этого ресурса. Разумеется, фактически требуемых ресурсов будет значительно меньше, чем идеально требуемых, однако это не повод для отказа от проекта. Прежде всего, потому, что ресурсы имеют свойство в известной мере компенсировать друг друга. Например, недостаток времени может быть компенсирован привлечением большего числа специалистов, а недостаток знаний и опыта, приведший к низким характеристикам быстродействия программного обеспечения, может быть скомпенсирован использованием более быстрого аппаратного обеспечения.
По окончании анализа ресурсов полезно составить перечень материально-технического обеспечения проекта и, в случае необходимости, смету проекта.
На этом этапе стадия предпроектной подготовки завершается. Начинаются стадии принятия решения и старта проекта - о них в следующем материале.
Автор: Глеб Похитонов
Источник:
Люди, инструменты, процессы
Программная инженерия
Форумы проектов
Последние новости и пресс-релизы компаний
Статистика
Исправляйте ошибки
