Управление ИТ и тп. Современные технологии делопроизводства и документооборота
 Скачать 1 Mb.
|
В другую крайностьСтолкнувшись со сложностью и неадекватностью численных расчетов по существующим методикам, многие уходят в противоположную крайность и объявляют ИТ чистыми, "вынужденными" затратами, разновидностью убытков, наравне с кражами, пожарами, наводнениями и прочими факторами, находящимися вне объективного контроля. Либо же отводят им роль качественных (соответственно - непросчитываемых и неучитываемых) улучшений. Таких как "сокращение дублирующих функций, увеличение оперативности расчетов, повышение "интеллектуальности" бизнеса, оптимизация управления" и т.д. Это - уже хорошо, по крайней мере, в этом нет явного обмана. Но такой подход все равно не дает ответа на главный вопрос "Если на ИТ тратятся вполне конкретные и прекрасно измеряемые средства, то как измерять то, на что эти средства тратятся". Для ответа на этот вопрос необходимо отойти от мелких, конкретных деталей и посмотреть на ситуацию сверху, "с высоты птичьего полета". Если это сделать, обнаруживается, что проблема, которую не удается решить - просто отсутствует. Действительно, качественная оценка - это инструмент принятия решений. А численная - это инструмент бухгалтерского и/или управленческого учета. В силу этого, любые сложности с оценкой (за исключением недостатка/неточности анализируемых данных), - это исключительно следствие непонимания самой природы оценки, а чаще всего - отсутствие конкретной цели проведения оценки. Если "качественная" оценка позволяет принять правильное решение - значит, она полностью справляется со своей задачей. Если численная оценка позволяет осуществлять бухгалтерский/управленческий учет - значит, она полностью справляется со своей задачей. Любая оценка - это не "данность свыше", а всего лишь инструмент. Инструмент, который надо определенным образом использовать для достижения четко поставленных целей. То есть - сначала определяется цель оценки, а уже потом, исходя из нее - определяется, какую конкретно оценку для достижения этой цели использовать, и как эту цель с помощью выбранной оценки достичь. Иначе будет бессмысленное использование инструмента не по адресу, без цели, без толку и без должного результата. Грамотное применение оценкиРазобравшись с природой оценки, можно вернуться к первоначальной задаче и попробовать ее решить. Начнем с оценки качественной, или, если точнее, нечисленной. Основная ее цель - обосновать принятие управленческого (в большинстве случаев) решения. Это решение касается "вложения" в новые ИТ (приобретение / разработка / внедрение). Соответственно, ответ должен иметь формат "вкладывать"/"не вкладывать", и/или "вкладывать в ИТ №1"/"вкладывать в ИТ №2". Эти вопросы решаются инструментарием стратегического менеджмента, и глобального маркетинга, исходя из целей/динамики развития компании/рынка. Бухгалтерское жонглирование цифрами здесь неуместно, основной инструмент - метрика "перспективности". Используемые понятия - "выход на рынок", "доля рынка", "расширение присутствия на рынке", "удержание рынка" и т.д. Если оценка не численная, значит ли это, что она не имеет цифрового "отражения?" Нет, не значит, наоборот - цифры здесь будут, просто идти они будут не от ИТ, а от рынка. Например, руководство транспортной компании (ТК) видя, что на рынке начинает усиливаться конкуренция, после рассмотрения альтернатив (снижение себестоимости/повышение оперативности перевозок) принимает решение сделать ставку на оперативность, для обеспечения которой рассматривает возможность приобретения соответствующей ИТ-системы. Соответственно, и сама эта система будет оцениваться исключительно исходя из метрик рынка перевозок, а отнюдь не из метрик рынка ИТ-систем. И если руководству компании необходимы цифры, можно, например, экспертно оценить увеличение доли рынка перевозок, соответственно - увеличение дохода, после чего "по вкусу" подобрать методику оценки, с помощью которой арифметическими манипуляциями "нарисовать" наборы цифр. При этом, естественно, нужно понимать, что никакой смысловой нагрузки эти цифры нести не будут, так как решение о "вложении" принимается отнюдь не на их основе, наоборот - сами эти цифры появляются из этого решения. Что же касается самих ИТ-компаний, которые сами "вкладываются" в нематериальные активы, и у которых подобные активы составляют основную часть "капитала", то для них разница между реальной и "нарисованной" стоимостью тем более может быть очень значительной. Так, компания IBM приобрела фирму Lotus по "рыночной" цене в $3,5 млрд. в то время как ее "бухгалтерская" (балансовая) цена составляла всего лишь $226 млн. А "рыночная" цена (капитализация) компании Microsoft превосходит "бухгалтерскую" на два порядка. Теперь - оценка численная, которая используется для управленческого/бухгалтерского учета. Из чего следует, что она никакой оценкой не является, это просто инструмент учета. Из чего в свою очередь следует, что использовать этот инструмент нужно, исходя исключительно из имеющихся задач. Все множество данных задач можно разделить на два подмножества: "учета приходов/расходов"и чистого "рисования цифр". Задачи учета приходов/расходов - самые обычные, традиционные задачи учета: кому и сколько заплачено, от кого и сколько получено, что на баланс принято, что с него снято и т.д. По большому счету это - инвентаризация, такой своеобразный аудит, "встречная проверка" на основании первичной документации с минимумом субъективизма. Другое дело - численная оценка в виде "рисования цифр". Вот здесь уж показывает себя аудиторско-бухгалтерская эквилибристика с мастерским использованием "методик" и профессиональным оформлением первичных документов. Приведем ряд характерных примеров. Транспортная компания (ТК) хочет приобрести у нашей компании программную систему оптимизации перевозок. Если система еще не создана, мы можем создать ее полностью или заключить с ТК договор о совместной разработке (возложив на ТК, например, задачи выработки спецификаций, тестирование и т.д.), либо можем просто временно передать своих специалистов ТК для разработки (в этом случае - это будет полностью ее разработка). Сами разработчики - при этом будут сидеть в одном и том же месте (при должном оформлении), а вот статусы получаемого продукта в этих трех случаях окажутся совершенно разными. Соответственно, разными будут и методики оценки стоимости получающейся в результате системы, а значит и результаты. В продолжение 1., - если нам самим нужна некая система - можем сделать ее сами (и оценить/учесть ее по себестоимости создания), либо заказать/купить ее у своей компании (и оценить/учесть ее - уже по цене приобретения). Систему по п.1. - можем ТК продать, а можем - сдать в аренду, либо - заключить договор на тестирование и поиск ошибок. Если нужно систему по п.1. переоценить с повышением ее стоимости, достаточно добавить функциональность или провести дополнительное тестирование. Если нужно сделать уценку, достаточно быстренько выпустить следующую, "обновленную" версию системы, и снизить каталожную цену "старой", либо найти ошибки/недочеты/отличие от спецификаций, и составить дефектную ведомость. В последнем случае - можно и немного денег из ранее уплаченных назад вернуть. Если нужно себестоимость еще увеличить и нормальной "первичкой" закрыть, можно оформить на систему максимум статусов (каждую картинку и все программные тексты оформляются как авторские произведения, с нормальным авторским договором, а то и лицензией). Если есть желание и способности, в дополнение к 6.можно все "обпатентить". Соответственно, на руках окажутся не просто "авторские договора", а пачка государственных охранных документов, которые и оценку дадут соответствующую. Под каждый патент можно оформить лицензионный договор, и тогда, помимо задирания оценочной стоимости, можно еще и налоговую оптимизацию организовать. То есть надо прямо брать методики и инструкции и, используя их как прямое руководство к действию, высчитывать оценку в строгом соответствии с ними, не забывая подставлять нужные коэффициенты. Во всех приведенных примерах речь идет не о подтасовке документов, а о выстраивании схемы работы таким образом, что ее результат любыми независимыми оценщиками будет оцениваться заранее заданным образом. И опять же - при этом нужно помнить, что все эти оценки не имеют никакого отношения к "рыночной" цене, которая определяется исключительно реальным покупателем, оплачивающим приобретение реальными деньгами. Вам "шашечки" или ехать ?В работе профессиональных ИТ-оценщиков очень редко, но все-таки встречаются ситуации, когда заказчик "для себя" хочет узнать, сколько в действительности стоит тот или иной ИТ-актив или, точнее, ИТ-решение. Как не трудно догадаться, в этом случае, никакие из вышеописанных "инструментов" не применяются. Как же осуществляется работа в таких случаях? Она строится как одновременная и совместная работа патентоведа, инженера, маркетолога и адвоката. С патентоведческой позиции оценивается мировая новизна решения по отношению к известному техническому уровню, с инженерной позиции - реализуемость решения, стоимость такой реализации, и получаемый технический эффект. С маркетинговой позиции возможная реакция рынка на появление данного решения, с учетом стоимости его реализации и времени его появления. Наконец, с адвокатской позиции оценивается уровень статусной поддержки решения (кому оно принадлежит и на каких условиях). По результатам рассмотрения решения со всех этих позиций выдается общее заключение, в котором описываются все плюсы и минусы решения. При этом существует достаточно большое количество минусов, при обнаружении которых дальнейший анализ прекращается. Так, если патентная экспертиза новизны решения еще не проводилась, оценивать его реализуемость и положительный эффект бесполезно, ибо оно может уже давно принадлежать кому-то другому. Если решение создано несколькими разработчиками, между которыми нет должным образом оформленных отношений, изучать технический эффект этого решения бесполезно, ибо даже если этот эффект будет положительным, непонятно, с кем и как впоследствии заключать контракт на использование этого решения. Или, например, если и отношения оформлены и патент выдан, но оформлен на десяток соавторов, то про его существование можно спокойно забыть, ибо ни один вменяемый покупатель лицензию по этому патенту не купит, а если и купит - то за копейки. В данном процессе присутствует очень много мелочей, каждая из которых может кардинально изменить всю результирующую оценку. Утешительные выводыИТ-активы и могут, и должны оцениваться для определения их стоимости. Данная оценка должна осуществляться в соответствии с многочисленными и достаточно подробно регламентированными методами и методиками. Все эти методы и методики являются инструментами достижения определенных целей и решения определенных задач, но сами по себе не содержат ни этих целей, ни этих задач. В том случае, если имеются четко определенные цели и задачи оценки, и имеется понимание принципов и механизмов самой процедуры, оценка может быть произведена с получением заданных результатов. Максимальный эффект при численной оценке ИТ-активов достигается не в виде манипуляций с методами и методиками, а в виде предварительной "обработки" (оформления) самого "объекта" последующей оценки с тем и так, чтобы любой сторонний оценщик при оценке данного объекта оценил его нужным нам образом. Волшебство нового программирования Владимир Пржиялковский, независимый консультант, координатор ЕАГПО Директор ИС, #03/2000 Уже не одно поколение программистов учат тому, что такое "промышленное производство программного обеспечения" и как выполняются проекты создания программных продуктов. Но именно сегодня эти вечные по компьютерным меркам представления начинают колебаться. Заявлено о новом (или даже "революционном") способе разработки ПО. Такое заявление не может не попасть в фокус внимания руководителей ИТ-коллективов. Хороший повод и одновременно хорошую основу для разговора о смене традиций в программировании дает появившаяся в конце прошлого года книга Эрика Рэймонда "Собор и базар" (The Cathedral and the Bazaar. Eric S. Raymond. O'Reilly & Associates. October 1999. 281 pages). В этой статье даются очень краткий обзор книги Рэймонда и начальные рекомендации руководителям - как перейти к использованию новых способов выполнения проектов ПО. Рэймонд и его книга Эрик Рэймонд - знаковая фигура в программировании. Это программист более чем с 20-летним стажем, поклонник научной фантастики, музыкант, обладатель черного пояса в таэквон-до. Здесь, однако, нас интересует другое. Последние несколько лет Рэймонд известен как главный идеолог движения "открытых текстов" (open source), того самого "нового" и "революционного". И в такой роли он выступает "представителем" Internet, ОС Linux, самого популярного в мире Web-сервера Apache. Это - системы-лидеры, но кроме них есть еще с десяток других программ, систем и проектов, названия которых на слуху, а сверх этого - еще сотни, пусть не имеющих такого глобального значения, но создаваемых на тех же принципах. Объединяет это пестрое множество разработок то, что все они без исключения осуществлены на некоммерческой основе "открытым способом". Это и дало Рэймонду основание прибегнуть для характеристики продуктивности нового способа к известному нам по старым сказкам образу "волшебного горшочка". Книга Рэймонда - это сборник основных и наиболее популярных его статей, по форме тяготеющих к эссе ("размышления" - пишет автор на обложке), уже публиковавшихся и не раз читанных им на конференциях за последние пять лет, но постоянно обновляемых по содержанию. В этих статьях метод открытой разработки систематизируется, подвергается анализу и осмыслению. Главный герой Главным героем книги, несомненно, является "хакер". Смысл, который Рэймонд вкладывает в это слово, существенно отличается от используемого в СМИ и принятого многими читателями. Хакер (hacker) в его понимании - это программист высокой квалификации, профессиональная деятельность которого совпадает с его увлечением: создавать новые "полезные" программы. Тех же, кого в обиходе именуют хакерами, Рэймонд называет кракерами (cracker) - программистами, занимающимися "взломом" чужих программ. Между первыми и вторыми большая разница. Хакер (по Рэймонду) создает новые программы для других и охотно делится своими "производственными секретами"; кракер же предпочитает работать в одиночку и секреты своего ремесла держать при себе. Очевидно, что интерес ИТ-руководителя к ним совершенно различен. Не надо думать, что хакеры обитают только в фирмах, ориентированных на создание программных продуктов. По утверждению Рэймонда, 95% всей программистской рабочей силы получает зарплату не за составление программ на продажу, а за сопровождение уже существующих или за создание программ для внутреннего пользования (предлагается посмотреть объявления о найме на работу). В этом случае отделы ИС для хакеров - родная среда. В этой среде они существовали всегда, то есть со времени появления компьютеров, и Internet с Unix не самые старые их творения. Что же нового у современных хакеров по сравнению с их предшественниками? Радикально изменился способ ведения работ, характерными чертами которого стали: а) массовость участников конкретных проектов; б) выход рабочих групп за пределы традиционных оргструктур путем создания виртуальных коллективов посредством Internet. Для Рэймонда хакеры и открытая разработка - две стороны одного явления. Согласно его идеологии, открытая разработка - это способ проявления профессиональной активности хакеров, а хакеры в свою очередь - агенты, реализующие способ открытой разработки. "Хакерское производство" Рэймонд рассматривает с самых разных сторон. Это - особая технология работы, культура и этика, мотивация и аспекты поведения. Кроме того, для открытого способа он рассматривает его соотношение с бизнесом, вопросы лицензирования и даже общеисторический человеческий аспект. Старый и новый способ организации программирования Преобладающий сегодня способ промышленного производства ПО сложился давно, к началу 90-х годов окреп и в целом стал восприниматься как естественный, само собой разумеющийся, копирующий производство материальных ценностей в капиталистическом обществе. Программы разрабатываются по схеме "сверху вниз", от идеи до эскиза реализации, затем - до его поэтапной детальной проработки и до создания (так же поэтапно) программных компонентов. Созданные программы - частная собственность фирмы-разработчика и могут продаваться по правилам, в основе своей общим для продажи автомобилей и книг. Программисты нанимаются фирмой и получают зарплату за своевременное и правильное выполнение поставленных перед ними задач. (Если не входить за рамки технологии, то тот же способ производства ПО был свойствен и социалистическому обществу в пору его существования.) В середине 60-х годов фирма IBM доказала, что "промышленным" способом можно производить и относительно небольшие системы, и большие программные комплексы. Еще через десять лет Брукс в своей нашумевшей книге "Мифический человеко-месяц" (вышедшей сейчас обновленным изданием, между прочим, и на русском языке) описал достоинства и изъяны такого способа. Вот пример изъяна по Бруксу: при увеличении числа программистов объем проделанной работы растет линейно, в то время как сложность проекта и стоимость организации взаимодействия растут квадратично. В результате подключение дополнительных программистских ресурсов к запаздывающему проекту отодвинет срок его выполнения еще дальше. Другой пример - это "вечная" проблема предсказания потребительной стоимости создаваемой системы: сколько раз случалось, что дорогостоящие разработки в конечном счете не находили спроса. В "хакерском" способе производства, новом уже с позиции наших дней, все наоборот. Программы составляются программистами для себя, а не по планам руководства (их потребительная стоимость по этой причине гарантирована!). Коллектив разработчиков извне неуправляем - подсоединиться к нему может любой имеющий выход в Internet - и неконтролируем. Исходный код программ открыт безвозмездно всем желающим. Рэймонд был одним из первых, кто в середине 90-х привлек внимание к такому факту: опыт проекта Linux показал, что открытым способом можно создавать не только относительно небольшие вспомогательные программки, но и ПО класса современных операционных систем. А вот один из показателей "революционности" нового способа: закон Брукса в нем не работает. Добавление новых участников в проект не только сокращает время выдачи результатов, но и повышает качество продукта. Модель открытой разработки В общих чертах модель открытой разработки выглядит так. Одним из основных понятий является проект. Проект - это совокупность работ, осуществляемых для достижения некоторых объявленных целей. Нужно сразу оговориться, что к целям проекта отношение может быть достаточно вольное и со временем они могут видоизменяться - существенно или не очень. Имеется держатель, или хозяин, или владелец (owner) проекта, то есть один или несколько программистов, осуществляющих сразу несколько важнейших функций: общую координацию работ по проекту, сбор и обработку поступающих заявок и мнений, сбор и обработку поступающего кода, формирование и опубликование версий продукта. Наконец, есть участники, или конкретные исполнители, осуществляющие программирование, отладку, тестирование и принимающие участие в обсуждениях и подготовке рекомендаций. Присоединиться к участникам может любой пользователь Internet, обладающий необходимым уровнем подготовки (без нее участие будет фикцией). Участники формируют общественное мнение, определяющее направление развития проекта. Второй важнейшей составляющей импульса развития проекта служат решения, принимаемые держателем. Держателем можно стать в четырех случаях: получив это звание по наследству от предыдущего держателя; объявив себя таковым вместе с объявлением нового проекта; объявив себя таковым вместе с объявлением нового проекта, "отпочкованного" от уже имеющегося; объявив себя таковым для "заброшенного" проекта, не проявляющего активности в течение длительного времени. Пример: Линус Торвальдс, бессменный руководитель проекта по созданию открытого ядра ОС Linux, стал им в соответствии с п. 2, то есть явочным порядком. Сам Рэймонд - руководитель проекта по разработке программы для передачи сообщений электронной почты fetchmail, ставшей повсеместной в Internet, оказался таковым по наследству, в соответствии с п. 1. "Отпочкование" проекта (п. 3) выполняет очень важную регулирующую роль, при отсутствии которой описанная схема была бы неработоспособна. Возможность "отпочкования" декларируется, но на практике не приветствуется и скорее служит организующим воздействием на держателя, аналогичным праву на забастовку в обычном производстве. "Отчего все не так?" Для руководителей служб ИС описанная выше модель - крепкий орешек, разгрызть который не очень-то помогает даже такой ее знаток, как Рэймонд. Что имеется в виду? Вот типичные задачи, к выполнению которых привыкли руководители традиционных проектов: формулировка целей проекта, определение и согласование индивидуальных целей каждого участника; отслеживание хода выполнения проекта, с тем чтобы не пропустить в работе важных деталей; поддержка мотивации участников, с тем чтобы они не начали пренебрегать рутинной деятельностью; распределение работ между участниками, обеспечивающее высокую эффективность использования каждого; выделение и распределение ресурсов, обеспечивающих бесперебойность хода работ. Столкнувшись с моделью открытой разработки, руководитель проекта увидит (с удивлением для себя), как привычные функции сразу теряют свой смысл или изменяются до неузнаваемости. Ресурсы распределять не надо, так как добровольные участники сами подключаются к работе с тем, что имеют, - со своими компьютерами и прочими устройствами. Организовывать людей привычным образом не требуется: дешевле найти в Internet несколько специалистов высокой квалификации, понимающих, как и что следует делать, чем набрать традиционную группу программистов, рассадить их по комнатам и каждому объяснять его задачу. Мотивациями участника проекта (по крайней мере, преобладающими) являются его собственный интерес и желание самореализации. И так далее. В игру вступают новые категории: добровольность и творчество, а это, согласитесь, не такое уж привычное для традиционного менеджмента поле деятельности. В модели открытой разработки держатель ("руководитель проекта") уже не может назначать, требовать исполнения и вообще диктовать свои требования. Иначе он рискует остаться без "своей армии" либо получить "отпочкование" несогласной части. Как утверждает Рэймонд, такие ситуации имели место в жизни. Самой известной "неудачей" (почему в кавычках - см. ниже) использования модели открытой разработки является пример mozilla.org. В начале 1998 года фирма Netscape опубликовала исходные тексты браузера Communicator, дав начало проекту открытой разработки с организованным ею держателем (группа лиц). (Фирма продолжает разрабатывать коммерческий браузер, но "отпочковала" от него открытый проект.) Читатель может зайти на mozilla.org и убедиться, что проект жив и развивается, однако ожидавшегося "взрыва" активности, сравнимого с Linux, увы, с ним пока не получилось. Случай с Netscape - тема для осмысления, но не сыграло ли здесь роль отсутствие согласованности между держателем и участниками проекта? Например, из-за того что держателем проекта была сделана попытка навязать свой интерес и свои правила работы? Что должен решить для себя руководитель отдела ИТ Новый способ разработки ПО стал настолько заметным явлением, что ИТ-руководителю все труднее откладывать ясную формулировку своего отношения к нему. Считать ли его набором совпадений, тенденцией или делом будущего? Стоит или не стоит его использовать в своей практике, и если да, то как, в какой степени? Понятно, что в ваших планах - вполне конкретные задачи и вы не собираетесь оповещать о них весь мир через Internet и не имеете возможности нанять сотню дополнительных программистов со стороны для ускорения работ. Но подумайте и о другом. Конечно, в области "промышленных" ПО-проектов традиционализм, как и в крестьянском деле, разумен, гарантируя проверенный опытом результат. Но жизнь - штука не всегда предсказуемая, и вот она дарит вам (и не только вам!) готовый и эффективный способ ведения программных разработок. Что мешает проверить его "примеркой на себя"? Осторожность понятна, но ведь полностью переходить на новый метод не требуется. Есть немало фирм, совмещающих ту и другую практику. Взять хотя бы десятки компаний, занимающихся распространением той же Linux. Мне кажется, что самая большая сложность, поджидающая руководителя, - это необходимость перестройки привычных образов его собственного мышления и действий. "Новое программирование" не имеет такого количества детальных моделей и такой проработки метрик, какое имеет "старое" (это не случайно: помимо фактора новизны здесь еще и противоположная направленность конструирования, не "сверху вниз", когда принципиальной является последовательность "модель - результат", а "снизу вверх", где роль традиционного моделирования то ли исчезает, то ли видоизменяется). Это может настораживать. Однако не следует забывать, что общая неэффективность традиционных подходов тоже всем известна. "Процент проектов, оканчивающихся неудачей", "процент проектов, перебравших все планировавшиеся ресурсы" и т. д. - высокие значения этих показателей давно стали общим местом. И это несмотря на то, что чаще всего на бумаге в проекте ПО все смотрится гладко! Так может быть, новая модель программирования - это действительно шанс на перспективу? Рекомендации руководителю Рэймонд не пишет подробно о том, как фирме или отделу ИТ подключиться к практике открытых разработок. Но кое-что он на эту тему говорит. К тому же в каких-то случаях выводы достаточно очевидны и их вполне можно сделать за автора книги. Попробую изложить их в виде нескольких рекомендаций. Найдите место открытому ПО в своем отделе Не исключено, что такое ПО у вас уже есть (вы можете об этом и не знать). Если в вашем подразделении используется Unix, то вполне вероятно, что на ваших компьютерах обнаружится и транслятор gcc, и упаковщик GNU tar, и языки сценариев Tcl, Perl или Python, а то и весьма развитая система резервного копирования/восстановления многомашинных сред AMANDA. Если ваша операционная среда - Windows, не исключено, что ваши программисты уже используют те же Perl и Python или (о чем могут благополучно не подозревать ни вы, ни пользователи) файл-сервер и сервер печати Samba. Вот важный тезис: не надо бояться использования открытого ПО. При имеющихся у каждого конкретного программного продукта недостатках (а недостатки есть и у "закрытых", то есть коммерческих программных продуктов), это ПО проверено массовым употреблением. Достаточно надежные оценки числа используемых копий для отдельных "открытых" программных продуктов достигают нескольких миллионов. Узаконьте использование открытого ПО в своей работе (естественно, контролируя сам процесс, номенклатуру и масштаб) и научитесь работать с ним в том, что касается сопровождения, обновления версий, нахождения выхода из проблемных ситуаций и т. д. Ваши программисты подскажут вам конкретные шаги в этом направлении. Для вас как начальника эти процессы могут выглядеть совершенно непривычно, так что к ним придется приспособиться. Сделав это, вы приобретете значительно больше уверенности, когда вам придется принимать более серьезные для себя решения, например об использовании Linux в качестве ОС и Apache в качестве Web-сервера для критичных узлов своей вычислительной инфраструктуры. Дайте сотрудникам хороший доступ в Internet Мне приходилось встречать рабочие коллективы, в которых запрещено пользоваться Internet, по крайней мере в рабочее время. Логика рассуждений руководства таких коллективов понятна, но не менее ясно, что при переходе на использование открытого ПО ее придется поменять. От запрета на использование Internet понадобится перейти к его контролю. Без Internet (не intranet или extranet, а именно без Internet) работать с открытым ПО нельзя. Там лежат в исходном или откомпилированном виде все программы открытого ПО и регулярно появляющиеся обновления. Там находится документация по открытым продуктам - а она в некоторых случаях тоже обновляется активно. Там находится масса полезных ссылок, неутомимо плодящихся трудами ваших "невидимых сотрудников" - программистов, круглосуточно работающих в самых разных уголках земного шара. Наконец, там находится множество "групп поддержки", где к вашим услугам - консультанты со всех концов света или даже сами авторы ПО. Система мер контроля - отдельная тема. Возможно, речь должна идти об ограничении адресного пространства доступа. Возможно - об ограничении числа компьютеров, которым будет позволен выход в "большую Сеть". Проконсультируйтесь со своими специалистами, но так или иначе работу с Internet придется узаконить и освоить. Научитесь работать с группами новостей В группах новостей ведется большая часть дискуссий, проектов и консультаций, касающихся конкретных продуктов или правового регулирования их распространения. Как минимум в группы новостей придется обращаться по конкретным вопросам использования ПО. Однако группы новостей - это та технология, которая в состоянии обеспечить большее, а именно достаточно развитую поддержку групповой работы в проекте. Самыми оптимальными по соотношению "стоимость/возможности" средствами для работы с группами новостей являются Outlook Express и Collabra (Messenger) соответственно фирм Microsoft и Netscape. Их способность поддерживать групповую работу подтверждена практикой, например, такого большого издания, как журнал BYTE. Заведите в своем отделе хакера Для начала хотя бы одного, ведь хакер - это особый стиль работы и особая культура. К тому же для "традиционного" начальника хакер - непривычный сотрудник. Это относится, например, к уже упоминавшейся хакерской мотивации. Обычный программист делает то, за что ему платят, и получает за то, что сделал (иногда даже сдельно). Хакеру же приходится платить за то, что он сделает и без денежного вознаграждения! Как отмечает Рэймонд, хакерская мотивация работы базируется на реализации своего профессионализма и на предоставлении результатов своей работы максимально широкому кругу заинтересованных лиц. Такая мотивация ставит перед начальником непривычные проблемы выведения оклада, но она же задает направленность критериев, которые следует принимать во внимание при создании хакеру среды, позволяющей добиться от него наибольшей продуктивности. Другим непривычным для традиционного руководителя поведенческим аспектом хакера является его малая (по сравнению с "обычными" сотрудниками) управляемость. Тем не менее настоящий хакер может стать очень эффективным сотрудником сам по себе. Кроме того, его временами раздражающее "сидение в Internet" ("разве за это ему деньги платят?") способно обернуться подключением колоссального и дарового потенциала профессионалов, работающих во всемирной Сети! Наконец, открытость хакера - тоже часть его мотивации, поэтому всеми своими находками настоящий хакер поделится с остальными сотрудниками. Найдите возможность для открытой разработки Осуществление перечисленного будет особенно полноценным, если вы сумеете среди своих производственных задач выделить актуальную не только для вас, но и для многих других. Она не должна составлять коммерческую тайну, чтобы можно было открыто обсуждать ее даже с фирмой-конкурентом. Ваша цель - потренироваться не только в использовании готовых открытых продуктов, но и в обкатке открытого метода разработки в своем коллективе. Естественно, что для начала задача должна быть некритичной для производства, но и не праздной. Возможно, это написание драйвера для только появляющегося устройства или сценария фильтрации электронной почты. Скорее всего, это окажется не прикладная, а системная задача. Однако и примеры открытых прикладных разработок тоже существуют. Сошлюсь на проект "Открытая бухгалтерия", ведущийся в Петербурге. Вы можете предложить внешней общественности свой вариант сценария фильтрации, например, в телеконференции в Internet. Ваши программисты подскажут, как это лучше сделать. Если сценарий актуален, вы имеете шансы через некоторое время получить отклики с улучшенными, исправленными вариантами или дополненными для тех ситуаций, которые вы не учли. В любом случае вы окажетесь в выигрыше и поймете на практике, как работает модель проекта открытого ПО. Чем шире интерес к вашей задаче, тем эффективнее такой механизм сработает. Но может оказаться, что ваши задачи совсем специфичны и объявление их во "всенародную разработку" ни к чему не приведет. Что ж, придется их решать самим или заказывать другой фирме, специализирующейся на таких задачах, - ведь даже энтузиаст открытой разработки Рэймонд не утверждает, что она единственна или универсальна как метод. Вы можете избрать и более решительную тактику. Положим, ваш отдел должен предложить техническое решение для надежно работающего круглосуточно Web-сервера, обрабатывающего большие потоки данных. Перед вами три возможности: купить коммерческий сервер; разработать свой собственный Web-сервер; присоединиться к группе разработки Apache. Конечно, у первого решения могут быть свои веские доводы "за". Но не нужно забывать, что: а. внешний разработчик при создании своего продукта не учитывал конкретику ваших условий; б. все равно вам придется потратить массу времени на настройку сервера, поиск ошибок и путей их обхода и т. д. Второе решение не такое уж надуманное: программисты утверждают, что сложность Web-сервера ниже сложности Web-браузера. Но далеко не все могут выделить на этот проект рабочую силу и время в необходимом количестве. Зато третье решение в состоянии обеспечить вам доступ к исключительно широкой базе опыта эксплуатации Apache в самых разных условиях. По некоторым данным, доля Apache среди общего количества серверов в мире составляет 61%, а по недавним оценкам Computerworld Россия, для домена ru эта цифра еще больше - 78%. Размер "базы знаний" и размах "консультационной поддержки" по Apache в Internet намного превосходит все аналогичное для других серверов и затрагивает все желаемые уровни - от простого использования до перепрограммирования компонентов. Что дает волшебство Звонкие слова, вынесенные в заголовок статьи, заимствованы из книги Рэймонда. Есть много людей, которые, не теряя почвы под ногами, видят в открытых разработках большое будущее. Другие считают, что это выдумки. "Большая промышленность" начинает проявлять благосклонность к отдельным "открытым" продуктам, но по поводу открытого способа разработки пока "окончательного" слова не сказала, так что ее действия могут трактоваться по-разному. Oracle, IBM и Informix, много других крупных и мелких фирм включили поддержку ряда систем открытой разработки в свои планы. Sun и Inprise/Borland открывают пользователям исходные тексты своих продуктов. Эти и другие фирмы поддерживают создание открытых Internet-форумов пользователей своих систем. Но о мере общего влияния открытых разработок на "большую промышленность" говорить пока рано. Однако по прочтении книги Рэймонда становится совершенно ясно: а. ставки высоки; б. конкретные действия по приобщению к открытым разработкам могут стать для вас своевременным мостиком в будущее. Процессное управление IT-структурой организации Алексей Брызгалов, директор по развитию компании "ОТР" Опубликовано на E-xecutive Процессно-ориентированная структура IT-департамента предприятия Что дает процессно-ориентированная структура IT-департамента организации? Как при такой работе IT-департамента возможен эффективный аутсорсинг IT-решений? Такие вопросы очень часто возникают при создании IT-подразделений крупных и средних организаций. В данной статье не ставится задача обсудить преимущества и недостатки традиционного функционально-структурированного подхода к организации IT-департамента. Это может являться темой отдельной статьи, более того, этот вопрос касается не только IT-подразделений, а организаций в целом. Хотелось бы, чтобы заинтересованные читатели задумались о том, что возможно текущая организация работ IT-подразделения исчерпала себя и новые бизнес задачи пора решать по-новому, в том числе с помощью сторонних организаций. Думается, неспроста многие IT-компании (как поставщики ПО, так и системные интеграторы) построены по проектному принципу, а все основные корпоративные стандарты по обеспечению качества ориентированы именно на процессы. Отсутствие же в таких компаниях указанной модели управления, как правило, определяется тем, что или нет возможности подобрать квалифицированных проектных менеджеров, которых действительно нужно найти, организация достаточно мала и количество заказов также невелико. Преимуществом процессно-ориентированной организации (это верно не только для IT-подразделений) является: Объединение отдельных подразделений в единую цепочку. Делегирование полномочий по отдельным задачам (снятие нагрузки по контролю с руководителя). Снятие барьеров и функциональных дыр, полученных в результате работы принципа "я отвечаю только за это", в случае, если над достижением результата работает несколько подразделений. Разделение обязанностей с целью минимизации риска зависимости от отдельного исполнителя, в случае, если работы исполняет один человек, заключающий в себе ВСЕ знания о том, как и что надо сделать (в качестве примера: часто встречается ситуация когда бизнес-пользователи взаимодействуют с разработчиком напрямую). Возможность стандартизировать требования к исполнителям и операциям, которые они выполняют, определив порядок взаимодействия исполнителя в процессе, тем самым, снижая риск зависимости от конкретной личности исполнителя, а не от его навыков и способностей. Возможность более гибкого реагирования на изменение внешних требований, предъявляемых к IT. Определение процессно-ориентированной организации. Дадим ряд определений: Проект - это временные действия, предпринятые для создания уникального продукта или услуги. Процесс - это постоянные действия, направленные на создание различных однотипных продуктов и услуг и улучшения их качества. В чем отличие процесса от проекта? Проект это, действия, возобновление которых не рассматривается при появлении необходимости создания нового продукта (это уже будет другой проект). Процесс же - это последовательность операций (набора действий), которые позволяют создавать различные уникальные продукты и/или услуги (здесь уникальность измеряется содержанием результата), не изменяя при этом их состава и порядка исполнения. Процессно-ориентированная организация IT - это организация, которая может обеспечить внутри предприятия непрерывный процесс производства IT-продуктов и услуг, включая обеспечение контроля качества результата на протяжении всего процесса производства при взаимодействии различных подразделений. Поэтому процесс контроля достижения КОНЕЧНОГО результата, контроля того, чтобы результат соответствовал требованиям заказчиков, становится в таких организациях одним из важных. Понятно, что для IT- подразделений заказчиками являются бизнес-подразделения. Продукты IT-подразделений Какие продукты и услуги производят IT-подразделения? Не будем стремиться к абсолютно полному их перечислению, ограничившись лишь в данном материале наиболее общими, чтобы в дальнейшем их классифицировать. Сразу оговоримся, что не все перечисленные ниже в качестве примера продукты и услуги, характерны для IT-подразделений всех предприятий. Понятно, что их набор зависит от величины организации и от стратегии развития IT. Итак, основными задачами, решение которых обеспечивает IT-подразделение, являются: Проектирование и реализация решений для поддержки новых бизнес-продуктов. Автоматизация документооборота. Регламентация операций (как минимум при работе с автоматизированной банковской системой). Внедрение технологий, обучение пользователей. Расследование "технологических" ситуаций. Обеспечение разграничения доступа к информационным ресурсам. Консультации подразделений предприятия (организации) при совершении операций с помощью используемого программного обеспечения. Предоставление различного рода сервисов, вплоть до организации доступа к сетевым ресурсам (принтера, факсы, файл-сервера и т.п.). Установка новых рабочих мест. Организация и обеспечение взаимодействия с филиалами. Сопровождение информационных систем предприятия. Сопровождение информационных порталов предприятия. При этом во всей деятельности IT-подразделения можно выделить два основных направления: Развитие технологий - сюда входят процессы, обеспечивающие внедрение решений, связанных с изменением технологий проведения операций предприятием. Сопровождение технологий - сюда входят процессы, обеспечивающие поддержку текущей деятельности организации. В добавлении хотелось бы отметить, что в процессно-ориентированных организациях действует принцип, сформулированный Хезером Остерлохом: "Необходимо обеспечить подчинение структуры процессам, а процессов стратегии". Поэтому выделение бизнес-процессов для IT-подразделений нужно рассматривать не только с точки зрения продуктов и услуг, но и с точки зрения бизнес стратегии организации Задачи IT-подразделений и стратегия развития. На сегодняшний день огромное значение для обеспечения эффективной деятельности предприятия играет наличие полнофункциональной единой корпоративной информационной системы (КИС), которая объединяет управление финансами, персоналом, взаимоотношения с клиентами, а также оптимизирует существующие в организации бизнес-процессы. Такие системы рассматриваются как средство достижения основных целей бизнеса, а именно: улучшение качества предлагаемых услуг, увеличение объема услуг, занятие устойчивых позиций на рынке. План по достижению бизнес целей при использовании IT-решений - является IT-стратегия (см. рис. 1 )  План - это список работ, которые в случае IT-стратегии приравниваются к списку проектов, которые должны быть реализованы для достижения целей, ставящихся перед ИТ- подразделениями, которые в свою очередь вытекают из стратегии развития бизнеса и организационной структуры, реализующей этот бизнес. И если цели, выдвигаемые к IT подразумевают, что необходимо обеспечить поддержку бизнеса при частом изменении технологий и высокой взаимозависимости между функциями, при частых и непредсказуемых изменениях бизнес окружения, когда требования к продукции или услугам диктуются уникальным рынком, регионом или потребностями конечных потребителей, то наиболее подходит конечно процессная организация исполнения работ. Процесс построения и развития КИС не может рассматриваться отдельно от технологии проведения операций, не может ограничиваться только работой с прикладными программами, с системным обеспечением или с "железом". В ситуации, когда происходит укрупнение предприятий либо создание финансовых холдингов, роль технологий выходит на первый план. Без грамотно выстроенного процесса сбора достоверной информации ни CRM, ни MIS не построить. Следствием возрастающей потребности во внедрении, развитии и сопровождении КИС является повышение требований к IT-подразделениям и к персоналу. Более того, перед IT-подразделением, как правило, уже не ставится цель типа "Поддержание серверов и программ в работоспособном состоянии". Перед IT в данном случае стоит цель: "Развитие и сопровождение технологии предприятия". Процессы, исполняемые IT-подразделениями. Представленное выше пояснение, касающееся бизнес-целей организаций, а также классификация работ (развитие или сопровождение) и введенное понятие технологии, позволяют определить основные бизнес-процессы, которые обеспечивает IT-подразделение предприятия: процесс развития технологии и процесс ее сопровождения, которые в свою очередь могут быть разбиты на несколько под-процессов (см. рис. 2 )  Перечисленные процессы, способны обеспечить выполнение задач, которые стоят сегодня перед IT-подразделением. Созданная процессно-ориентированная структура позволит уже не только оптимизировать управление задачами, но и убрать всегда неприятную для конечного заказчика "зависимость от конкретных исполнителей". В эту структуру должны войти специалисты различной квалификации: технологи, программисты, администраторы, менеджеры проектов, координирующие проекты и обеспечивающие контроль качества результата. В ходе своей деятельности наша компания не раз осуществляла постановку процессов развития и сопровождения IT. В результате проведённых работ IT-подразделение холдинга заказчика справлялось не только с задачами, связанными с профилирующей деятельностью, например, с банковской, но и развитием технологий, совершенно не относящихся к банковской деятельности, например, внедрение технологии работы сети магазинов. Поэтому можно с полной уверенностью сказать, что этот подход работает и подтверждает преимущества процессно-ориентированных структур (даже после ухода ряда ключевых руководителей и специалистов работы не нарушились). Аутсорсинг Любой из вышеуказанных процессов или отдельные задачи по созданию или сопровождению технологии предприятия могут быть переданы на аутсорсинг. Аутсорсинг - компенсация нехватки или замена внутреннего ресурса заказчика за счет привлечения внешнего подрядчика для выполнения определенных работ. По сути, аутсорсинг, это использование механизма и ресурса процессов внешнего подрядчика для решения задач заказчика. Потребность организаций, и в частности банков, в передаче на аутсорсинг некоторых объемов работ в области развития и сопровождения банковских и информационных технологий обычно возникает в следующих ситуациях: На начальном этапе организации и функционирования процесса развития и сопровождения технологии с целью обеспечения результативности вновь созданного процесса до подготовки необходимого количества персонала предприятия. В период резкого увеличения объемов работ по развитию технологии: внедрение новой информационной системы, развитие бизнеса - внедрение новых продуктов и услуг, реорганизация бизнес-процессов и т.п. В таких ситуациях объем работ значительно возрастает на определенный период, после которого предприятие может снова справляться своими силами. При желании и готовности организации полностью или частично переложить головную боль по развитию и (или) сопровождению технологии на специализированную компанию-подрядчика. При этом предприятие может избежать увеличения штата сотрудников или даже провести сокращение. Передача работ на аутсорсинг - задача ответственная. Поэтому важно то, кому и как она передается, как будет осуществляться контроль. Проблемы, связанные с аутсорсингом, минимизируются в случае качественной регламентации отношений между предприятием и подрядчиком, а также при постоянном контроле качества работ, выполняемых подрядчиком. Следует отметить, что при процессной организации внутренней IT-службы, при наличии документированных стандартов и требований к исполнителям и к результатам их работ, "подключение" ресурсов и процессов внешнего поставщика на условиях аутсорсинга за счет однородности "культуры" работ абсолютно гармонично, а, следовательно, наиболее эффективно и наименее рискованно. Резюме Целесообразность построения процессно-ориентированных структур очевидна в крупных организациях с развитыми IT-службами. Для небольших организаций с небольшой IT-инфраструктурой и IT-службой усилия на организацию IT-процессов, возможно, не столь оправданы, но являются основой для дальнейшего гармоничного развития IT и создают оптимальные условия для передачи определенного объема работ на аутсорсинг. Эволюция организации и ее рост должны обязательно приводить к эволюции IT-подразделения. Что выражается не только в увеличении численности сотрудников, но и изменении подходов к решению задач. От редакции: В последних числах октября было завершено подведение итогов исследования "Аутсорсинг программных услуг в России", которое проводилось по инициативе компании "Аплана" аналитическим агенством Elashkin Research при поддержке ИД "Компьютерра" в августе-октябре 2003 года. Исследование было предпринято с целью получения качественной оценки ситуации с аутсорсингом программных услуг и ИТ-услуг в целом на российском рынке. Основной задачей исследования стало выявление общего уровня востребованности аутсорсинга, мотивов обращения к этой модели, а также тех причин и рисков, которые влияют на рост популярности аутсорсинга программных услуг в России. В исследовании, проходившем в форме анкетирования и персонального интервью, приняли участие более 40 руководителей информационных служб крупнейших российских компаний и предприятий. Итоги исследования позволяют говорить о востребованности российским рынком модели аутсорсинга: 49% опрошенных отметили, что они уже работают в модели аутсорсинга. Доминирующей моделью предоставления программных услуг на сегодняшний день является аутсорсинг отдельных задач (42% респондентов), хотя достаточно активно используются и такие формы взаимодействия, как аутсорсинг ресурсов и аутсорсинг процессов. Следует отметить, что значительная доля компаний, принявших участие в исследовании (39%), пока находится на этапе выбора, что говорит о потенциале дальнейшего роста этого рынка. Основными мотивами обращения российских компаний к программному аутсорсингу являются нехватка собственных ресурсов - специалистов соответствующей квалификации, необходимость выполнения проекта в сжатые сроки и высвобождения внутренних ресурсов для решения других задач. При этом потребители услуг не рассматривают программный аутсорсинг как более дешевую альтернативу собственным ресурсам, а воспринимают как возможность получения качественного сервиса. Эту же тенденцию подтверждают и данные о критериях выбора поставщика услуг, которые свидетельствуют об ориентации заказчиков на конечный результат. Так, в качестве основных критериев выбора партнера по разработке респонденты указали способность поставщика оказывать качественные услуги, а также наличие у него опыта реализации аналогичных проектов. Стоимость услуг является значимым, но не определяющим фактором. В то же время такие факторы, как размер компании и ее репутация на рынке, а также существующие связи поставщика с заказчиком указаны в числе второстепенных критериев выбора партнера, что также свидетельствует о становлении рынка. К основным причинам, мешающим дальнейшему развитию рынка аутсорсинга программных услуг, потребители относят отсутствие видимого экономического эффекта от использования аутсорсинга и риски потери контроля или утечки важной информации. При этом значительная группа респондентов ссылается на недостаточное знакомство с возможностями аутсорсинга и ссылается на недостаток опыта, что также говорит о потенциале этого сегмента рынка. Как полагают авторы исследования, в этих условиях основным катализатором дальнейшего роста популярности модели аутсорсинга ИТ-услуг в России станут примеры успешного использования аутсорсинга российскими предприятиями. В то же время для успешного взаимодействия как поставщикам, так и потребителям услуг следует больше внимания уделять управлению рисками и тщательному планированию взаимодействия в модели аутсорсинга. Источник - информация компаний Elashkin Research и "Аплана" |