CustisWiki - Новые страницы [ru]

Не так легка дорога в облака

2014-10-17T15:07:22Z

OlgaChekhunova:

Ведущий системный инженер Дмитрий Морозов ответил на вопросы журнала «Системный администратор» о перспективах развития облачных сервисов в России. В каких случаях компании рациональнее отдать данные для миграции в облако и в чем плюсы и минусы облачных хостингов? Читайте об этом в материале «Не так легка дорога в облака».

Благодаря объединению больших ресурсов публичное облако предоставляет почти неограниченные возможности масштабируемости, гибкости и скорости развертывания. А концепция «сколько использовал — столько и заплатил» позволяет значительно сократить стоимость владения.

С другой стороны, основные проблемы, с которыми приходится сталкиваться при передаче сервисов в облака, — это отсутствие быстрых каналов связи и гарантий безопасности переданной информации.

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

Существенной проблемой для развития облаков остается отсутствие быстрых и надежных каналов связи. Последние несколько лет набирает популярность использование облака как резервной площадки для ИТ-инфраструктуры. Резервные копии хранятся в коммерческом ЦОД (оплачивается только хранение), и в случае проблем с основной площадкой ИТ-инфраструктура компании «поднимается» в облаке. Таким образом значительно снижаются издержки на резервирование, но этот подход требует ширины канала связи до облака. Если в столице проблем с этим практически нет, то в регионах все не столь радужно.

Облачные технологии продолжают стремительно развиваться. Это связано, в первую очередь, с серьезной конкуренцией среди провайдеров облаков. Практически все арендаторы ЦОД, которые не нуждаются в особой защите данных, уже «поделены» между провайдерами. В «войне» за держателей информации ограниченного доступа важным преимуществом провайдеров будет предоставление гарантий безопасности данных, потому на рынке наблюдается рост числа сертифицированных ЦОД.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Не так легка дорога в облака»

Какое образование должно быть у HR-менеджера?

2014-10-17T11:35:02Z

AlexandraVelyaninova:

На портале «Планета HR» опубликована статья Евгении Лопатиной, нашего менеджера по подбору персонала, посвященная HR-образованию. О том, какие вузы оканчивают современные HR, какими знаниями они должны обладать и как лучше повышать квалификацию в этой сфере, можно прочесть в статье «Какое образование должно быть у HR-менеджера?».

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

HR-партнер нашей компании — это специалист в области управления персоналом, который концентрируется на одном или нескольких бизнес-направлениях. HR-партнер принимает непосредственное участие в реализации бизнес-целей направления, задействуя вектор управления персоналом: он выстраивает и развивает HR-процессы и механизмы, совместно с руководителями направлений решает задачи по организационному проектированию — позиций, процессов, организационных конструкций. К операционным задачам HR-партнера относится курирование процессов подбора, адаптации, оценки и развития персонала, разрешение конфликтов и т. д. Крайне желательно, чтобы такой специалист имел высшее образование в области управления персоналом. Если первое образование психологическое или техническое, стоит получить дополнительное образование в области управления.

Позиция рекрутера — специалиста, занимающегося подбором кадров, — предполагает понимание особенностей отрасли, в которой работает компания (в нашем случае — сферы IT), и профессиональные знания в области психологии. Почему необходимо разбираться в тонкостях функционирования отрасли? Потому что невозможно качественно и эффективно подбирать персонал, не понимая специфику деятельности искомого специалиста, не разбираясь в том, какими навыками он должен обладать и какие обязанности будут на него возложены. Для чего нужно знание психологии? Крайне важно уметь видеть личностные качества соискателей, предугадывать их подход к разрешению проблемных ситуаций, моделировать процесс адаптации и предвидеть различного рода риски, связанные с вводом нового человека в команду. Обязательное требование к рекрутеру — высшее образование, гуманитарное или техническое. Плюсом будет наличие сертификатов о прохождении курсов или тренингов по подбору персонала.

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

Для рекрутера базовыми являются практический опыт подбора IT-специалистов различных направлений и/или навыки, полученные на курсах и тренингах по подбору персонала. Сегодня их выбор довольно большой, и можно найти тренинги IT-тематики, адаптированные специально для HR-специалистов. Кроме того, для нас очень важны личностные качества соискателя — коммуникабельность, системность мышления — и наличие интереса к IT-сфере. Обладая такой базой, рекрутер сможет постепенно развить навыки подбора специалистов с учетом потребностей бизнес-подразделений и стратегии компании в целом.

Говоря об «идеальном» HR-образовании, важно понимать, что высококвалифицированный HR-специалист сегодня — это управленец, глубоко понимающий бизнес-процессы своей компании. Но, к сожалению, далеко не все отечественные вузы успели перестроиться под новые потребности рынка HR-кадров. Большая часть знаний, которые будущие HR-специалисты получают в вузах, не отвечает потребностям бизнеса. Поэтому для успешной работы нужно постоянно дополнять и расширять полученное образование, заниматься непрерывным саморазвитием.

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

Репликация: База Знаний «Заказных Информ Систем» → «Какое образование должно быть у HR-менеджера?»

Бизнес-ориентированные HR-проекты

2014-10-17T10:37:19Z

AlexandraVelyaninova:

Наш руководитель отдела персонала Евгения Удалова рассказала порталу «Планета HR» о том, почему столь важно партнерство между HR и бизнесом, что такое «предпринимательская позиция» HR и какими качествами должен обладать настоящий HR-партнер. Обо всем этом — в материале Евгении «Бизнес-ориентированные HR-проекты: когда HR становится реальным бизнес-партнером?».

Говоря о бизнес-ориентированных проектах, нужно сразу отметить, что они возможны в первую очередь в компаниях, которые занимаются трудоемким и «персоналозависимым» бизнесом, когда кадры в прямом смысле «решают все». Речь идет, например, об организациях, оказывающих профессиональные услуги — по консалтингу, интертейнменту, архитектурно-дизайнерскому проектированию, IT-разработке.

Необходимое условие бизнес-ориентированного HR-проекта — это партнерство между HR и бизнесом, когда ландшафт бизнес-проекта формируется совместно. Здесь важно остановиться, поскольку понятие «партнерство» часто понимается HR однобоко — можно наблюдать перекос в сервисную модель (то есть предоставление заранее оговоренных сервисов) или в модель оказания VIP-услуги — «что изволите». Партнерство подразумевает равенство сторон, признание значимости каждого участника в совместной деятельности:

у партнеров есть общая цель, которая их объединяет;
каждый из партнеров имеет собственные цели, которые признаются важными обеими сторонами;
существует перечень вопросов, по которым не может быть принято единоличное решение, только совместное.

Примерами бизнес-ориентированных HR-проектов могут служить проекты по формированию нового, ключевого для бизнеса отдела или комплектованию региональных офисов компании — стоит лишь посмотреть на эти, казалось бы, операционные задачи HR под другим углом. Сюда же относятся проекты в области обучения и развития персонала — их реализация всегда является частью более сложной программы реорганизации или бизнес-ориентированных преобразований. Для меня вершиной HR-BP являются инвестиционные проекты по формированию HR-бренда, развитию корпоративной культуры. Результат такой деятельности сложно формализовать, практически невозможно свести к числовым показателям, к тому же эффект от таких инвестиций очень небыстрый, его еще нужно дождаться.

Конечно, выстраивание сотрудничества между HR и бизнесом в залоге партнерства не может быть задачей только HR — это смена принципов управления, которая должна быть поддержана на самом высоком уровне.

Что еще нужно, чтобы HR стал HR-BP? К счастью, все остальное в наших с вами руках, а точнее в области профессиональных и личностных компетенций HR. Пожалуй, самое важное ― то, какую позицию занимает руководитель HR по отношению к бизнесу. Он должен быть не «операционным руководителем» и даже не «реализатором стратегии компании», а «предпринимателем». Именно такая позиция задает ту рамку размышлений, постановки целей, планирования и реализации задач, которая позволит стать HR-BP. HR-партнер должен уметь:

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

Не стоит забывать, что «предпринимательская позиция» — это не только идеи, новые свершения, но и риски, на которые нужно идти, и ответственность перед бизнесом, которую нужно принимать.

Чтобы общаться с бизнесом, нужно понимать его цели и задачи и уметь разговаривать с ним на одном языке. Важно научиться смотреть на бизнес-ориентированные HR-проекты как на инвестиционные, что означает возможность:

оценить вклад, степень влияния на общий результат/реализацию целей;
дать оценку эффективности проекта (как результата, так и процесса);
рассчитать ROI или альтернативные показатели: ROE (return of expectation), Return ON (People, Knowledge, Time, Technology…) и т. д.

Обычно именно в этот момент HR хватается за голову, ведь финансовые термины, методики и подходы зачастую наша ахиллесова пята. На самом деле все не так страшно, важно захотеть в этом разобраться — есть много курсов и тренингов, информации в свободных источниках, в конце концов, можно обратиться за консультацией к специалисту. Главное — начать пробовать, ведь только так можно расти и двигаться дальше.

Репликация: База Знаний «Заказных Информ Систем» → «Бизнес-ориентированные HR-проекты»

Как создаются уникальные EVP

2014-10-17T09:50:35Z

AlexandraVelyaninova:

Наши менеджеры по подбору персонала Ольга Корсакевич и Мария Веденина рассказали порталу «Планета HR» о том, в чем состоит и как создавалось уникальное ценностное предложение нашей компании. Читаем статью «Как создаются уникальные EVP».

Чтобы понять, как появилось уникальное EVP нашей компании, нужно совершить экскурс в историю. В 1996 году несколько выпускников МФТИ решили собрать команду единомышленников для разработки учетно-аналитического ПО. Основными требованиями, которые предъявлялись к членам команды, были интеллект, интерес к делу и самостоятельность. Компания активно росла и развивалась, увеличивалась потребность в персонале, которая уже не могла покрываться имеющимся кругом связей и знакомств сотрудников. Конкуренция на рынке труда заставила тогда еще совсем молодую компанию искать ответ на вопрос, чем она отличается от других работодателей и что может предложить потенциальным сотрудникам.

В тот момент ответ был очевиден — решение сложных и интересных задач, работу в сообществе профессионалов, настоящих мастеров своего дела. Именно эти ценности закладывались в основу позиционирования нашей компании на рынке труда: мы расставляли соответствующие акценты в формулировках вакансий, давали кандидатам сложные технические тесты, и собеседования часто напоминали «дискуссию в клубе профессионалов». Наши специалисты начали выступать на профильных конференциях, писать проблемные статьи. Мы были почти у цели: вакансии успешно закрывались, к нам на работу выходили высококвалифицированные сотрудники…

Но реальность внесла свои коррективы. Если ожидания «новичков» относительно профессионализма коллег оправдывались в полной мере, то «зубодробительные» задачки и технические «головоломки» встречались не каждый день: не только из них состоят проекты. К счастью, мы сумели вовремя принять меры и удержать талантливых сотрудников, но стало очевидно, что наше EVP не в полной мере соответствует действительности.

Обычно компании, рассказывая о себе, совсем не предполагают никого обманывать или создавать себе ложный образ. Так произошло и с нами. Формулируя свое EVP, мы хотели предложить кандидатам самое лучшее и незаметно приняли желаемое за действительное. Нам потребовалось некоторое время, чтобы здраво и всесторонне проанализировать ситуацию.

В итоге мы поняли, что, помимо возможности работать над сложными, комплексными IT-проектами, серьезным преимуществом нашей компании является сама атмосфера доверия, взаимного уважения и поддержки, особая корпоративная культура, основанная на гуманистическом подходе, — то, что ежедневно проживается сотрудниками.

Атмосфера и культура нашей компании — это прежде всего открытость, которая проявляется на всех уровнях, начиная с самого верхнего.

Каждый сотрудник имеет возможность задать вопрос или высказать свои идеи руководству, и их обязательно услышат. Мы уделяем большое внимание информированию наших специалистов о жизни и планах компании, стараясь, чтобы каждый понимал, куда мы двигаемся и почему. Каждые две недели по вторникам мы собираемся в конференц-зале на традиционное «Доброе утро, CUSTIS!», где наш генеральный директор рассказывает о главных новостях и планах компании, собирает пожелания и подробно отвечает на любые вопросы. Краткое содержание встречи дублируется в личном блоге генерального директора, а сама встреча записывается на видео, чтобы все, у кого не получилось прийти, могли посмотреть ее в удобное время.

Мы абсолютно убеждены, что у каждого профессионала должна быть возможность открыто делиться своими идеями, соображениями и критикой с коллегами, — только так мы сможем поддерживать здоровую профессиональную среду, не давая людям и проектам «протухать». Наши специалисты постоянно дискутируют на профессиональные темы в корпоративном блоге, причем младший разработчик может в честном поединке «сцепиться» с руководителем подразделения, и это совершенно нормально. Более того, любой сотрудник может подготовить доклад на «животрепещущую» для него тему и выступить с ним перед коллегами. Результатом таких дискуссий и постоянного обмена знаниями является сплоченная команда профессионалов, а иногда в процессе рождаются нетривиальные решения реальных проблем.

Открытость для внешнего мира проявляется в нашей готовности делиться знаниями с клиентами, потенциальными сотрудниками и СМИ.

Уже на этапе собеседования мы стараемся дать соискателю как можно больше информации о нас: честно рассказываем о проекте, его плюсах и минусах, о тонкостях работы в целом. Так кандидат может принять взвешенное, осознанное решение относительно работы в компании.

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

Мы открыты для СМИ и профессиональных сообществ — наши специалисты дают интервью и комментарии, пишут экспертные статьи для IT- и бизнес-изданий, выступают на конференциях и семинарах. Два раза в год в компании проводятся циклы открытых семинаров IT-тематики для студентов и молодых специалистов, которым посвящена группа CUSTIS Young ВКонтакте, куда мы выкладываем все материалы выступлений, отвечаем на вопросы и собираем отзывы о прошедших встречах.

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

Подводя итоги, нужно сказать, что очень важно создать уникальное предложение компании-работодателя, честное, осмысленное и нешаблонное, но еще важнее постоянно «держать руку на пульсе» и поддерживать его актуальность. EVP должно быть привлекательным для новых сотрудников и оставаться «вкусным» для уже работающих. Чтобы этого добиться, мы регулярно проводим мониторинг рынка труда и устраиваем ежегодную оценку персонала, в ходе которой выясняем, насколько наше предложение соответствует потребностям специалистов. Мы систематически анализируем обратную связь от сотрудников, причины увольнений и отказа от предложений, мотивы выбора компании в качестве работодателя и т. д. — это тоже дает нам необходимую базу постоянных улучшений. Ведь, как бы ни был сложен этот процесс и трудноизмерим результат, главное — двигаться вперед и не сдаваться!

Репликация: База Знаний «Заказных Информ Систем» → «Как создаются уникальные EVP»

Отзыв о книге «Балдеющие от адреналина и зомбированные шаблонами»

2014-10-17T08:28:12Z

OlgaChekhunova: OlgaChekhunova переименовал страницу Балдеющие от адреналина и зомбированные шаблонами (отзыв на книгу) в [[Отзыв о книге «Балдеющие от адрена…

Портал theRunet.com опубликовал отзыв Дмитрия Звонарева, ведущего специалиста отдела персонала, на книгу Тома Демарко и Тимоти Листера «Балдеющие от адреналина и зомбированные шаблонами». Для кого и чем именно будет полезна эта книга читайте в материале «4 книги о работе с людьми. Рекомендуют профессионалы».

Эта книга написана не HR’ами и не для HR’ов, но она будет полезна всем, кто работает с проектными командами. За прочтение говорит уже тот факт, что авторы этого сборника — Том ДеМарко, Тимоти Листер, Питер Хрущка и Ко — признанные гуру в области управления IT-проектами. Опираясь на свой обширный опыт, они выделили наиболее распространенные паттерны поведения проектных команд, которые оказались очень схожими для разных наций и культур. Кроме того, выяснилось, что эти паттерны, обнаруженные на примере команд по IT-разработке, свойственны не только айтишникам, но и представителям других областей, в чем очень легко убедиться, «примерив» пару-тройку шаблонов на себя.

Мне кажется, что эту книгу можно посоветовать всем HR-специалистам независимо от специализации. Директора по персоналу и HR-партнеры смогут лучше понимать поведение проектных команд (и в целом любых профессиональных коллективов, работающих на общие цели), на ранних стадиях диагностировать проблемы — существующие и только назревающие — и вовремя принимать необходимые меры. Кроме того, понимание шаблонов поведения поможет в организационном проектировании и развитии. Рекрутеры научатся распознавать «носителей» тех или иных паттернов и учитывать это при оценке соответствия кандидата корпоративной культуре и «атмосфере» команды, в которой ему предстоит работать.

Читается книжка очень легко, в ней нет сложных технических терминов, что, несомненно, большой плюс для HR’ов, которые делают первые шаги в IT-отрасли (или вообще работают в другой сфере). Ну а тем, кто уже знаком с IT-спецификой, книга позволит по-новому взглянуть на известные проблемы. Отдельное спасибо хочется сказать авторам за отличное чувство юмора — заряд позитива и хорошего настроения всем читателям гарантирован :))

Репликация: База Знаний «Заказных Информ Систем» → «Отзыв о книге «Балдеющие от адреналина и зомбированные шаблонами»»

Централизация управления на основе интеграции ИТ — один из актуальных трендов в банках

2014-10-16T16:42:47Z

AlexandraVelyaninova:

Первый заместитель генерального директора Сергей Тихомиров ответил на вопросы редакции CNews о преимуществах внедрения единых интеграционных решений и значимости централизации управления в банках. Каковы мировые и отечественные тенденции в области централизации управления? Когда интеграционное решение становится инструментом развития? Насколько эти решения оправдывают вложения? Обо всем этом — в материале «Централизация управления на основе интеграции ИТ — один из актуальных трендов в банках».

CNews: Интеграция ИТ в банках — о ней много говорят и регулярно заявляют о выполненных проектах. Почему эта тема стала так актуальна?

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

Где-то на задачи интеграции смотрят как на сугубо инфраструктурные: если сквозной бизнес-процесс требует связать функциональные блоки, то это делается на локальном уровне — в рамках конкретной задачи и в минимальном объеме.

Преимущества внедрения единого интеграционного решения известны: во-первых, уменьшается связность компонентов ИТ-ландшафта; во-вторых, облегчается замена ИТ-компонентов в рамках выбранной стратегии изменений; в-третьих, появляется возможность в полной мере реализовать идею использования best-of-breed решений.

Это в принципе обеспечивает банку целенаправленное управление развитием — прозрачное и с просчетом рисков будущих изменений.

CNews: Чем интеграция информационных систем полезна с точки зрения бизнеса?

С. Тихомиров: Основная причина, по которой бизнес сейчас инициирует масштабные интеграционные проекты, — необходимость повышать эффективность работы организации в целом. Интеграция на уровне ИТ тесно связана с распространением централизованного управления на все сферы деятельности банка. Централизация управления — это один из актуальных трендов в крупных организациях.

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

Кризис приостановил этот процесс, а спустя год-два после его окончания принципы банковского развития изменились: борьба за эффективность бизнеса вышла на первые позиции. Для успеха в этой борьбе необходимо предварительно сделать организацию прозрачной и управляемой. Львиная доля всех ИТ-задач по централизации связана именно с обеспечением прозрачности и управляемости бизнес-процессов.

Еще одна важная задача централизации — это стандартизация деятельности банка, которая распространяется на работу всех отделений, операционных и функциональных подразделений, а также их взаимодействие.

Проекты по централизации управления проецируются в различные задачи на уровне ИТ. Например, нам приходилось выполнять работы по централизации учета и ведения единой учетной политики в банках. Консолидированный учет — бухгалтерский, управленческий, налоговый — выстраивается таким образом, чтобы от агрегатных показателей в балансе или конкретных строк в отчетах можно было «спуститься» до набора первичных документов, которые породили эти суммы. Так достигается прозрачность учета во всей организации, включая филиалы.

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

CNews: Как, по-вашему, тенденция к централизации управления в отечественных банках соотносится с мировыми трендами?

С. Тихомиров: Централизация управления не противоречит мировому опыту. Если продолжить тему учета, то подобные централизованные решения существенно облегчают и ускоряют внедрение международных стандартов Базель II и Базель III, что сейчас является трендом у российских банков. Это связано не только с интеграцией в западное банковское сообщество, но также обусловлено стремлением повышать эффективность. Основная идея Базельских правил — это переход к риск-ориентированному управлению, что отлично ложится в парадигму обеспечения прозрачности и внедрения централизованного управления через единую учетную политику.

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

CNews: Вы упомянули, что интеграция в ИТ может выступать как средство развития бизнеса. Какие условия необходимы для этого?

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

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

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

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

CNews: Не секрет, что отношение к большим интеграционным проектам не всегда однозначное. Насколько эти решения оправдывают вложения?

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

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

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

CNews: Не удорожает ли интеграционное решение эксплуатацию всей информационной системы в банке?

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

Есть прямые затраты, которые можно отнести на появление интеграционного решения, а есть косвенные — на те работы по интеграции, которые раньше включались в строку расходов на доработку конкретной системы. После внедрения единого интеграционного решения все косвенные расходы «отрезаются» от функциональных систем и переносятся непосредственно на него. Совокупная доля этих косвенных затрат оказывается существенно выше, чем затраты, напрямую связанные с его появлением. Кажется, что затраты на интеграцию возрастают, а на самом деле формируется адекватная картина реального распределения расходов.

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

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

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

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

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

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

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

CNews: Насколько успех интеграционного проекта зависит от ИТ-службы в банке?

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

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

А если ИТ-подразделение пассивно и действует из соображений «бизнес чего-то требует, и мы это быстренько и подешевле реализуем», тогда они просто не понимают, зачем от простых локальных связок нужно переходить к комплексной и сложной интеграции. Зачем усложнять себе жизнь, продумывать схему управления, выстраивать архитектуру, прогнозировать последствия — и брать на себя дополнительную ответственность за все это?

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

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

Если же он останется в ИТ, то будет интегрирована только часть ИТ-ландшафта и какие-то отдельные операции, — это будет выстрел «из пушки по воробьям». к сожалению, так нередко и случается: разворачивается инфраструктура и разрабатывается компонентная архитектура для банка в целом, но без поддержки на должном уровне все скатывается к решению текущих локальных задач.

CNews: Практически ко всем интеграционным проектам банки привлекают своих подрядчиков. Как заказчик и исполнитель должны делить зоны ответственности?

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

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

Большой интеграционный проект — это и не чисто внутрибанковская задача, и не классический аутсорсинг. Тут правильно создавать партнерскую среду для подрядчиков, чтобы постараться снять или хотя бы снизить неизбежные риски.

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

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

CNews: Стоит ли банку самостоятельно внедрять единое интеграционное решение или выгоднее прибегнуть к аутсорсингу?

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

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

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

Хотя придется повторить, что опыт реализованных интеграционных проектов в нашей отрасли еще невелик, поскольку реально построенных компонентных архитектур в банках практически нет. А поскольку однозначно хорошо завершившихся историй до сих пор нет, то и выбор среди отечественных подрядчиков, способных внедрять интеграционные решения в крупных организациях, пока невелик.

CNews: Что должно отличать подрядчика, способного выступать в качестве стратегического партнера банка по развитию ИТ?

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

Мы считаем, что все эти качества подрядчика должны опираться на прочную технологическую основу. Для нас такой основой при выполнении интеграционного проекта является подготовка прототипа. Поскольку создается решение стратегического уровня, нельзя сразу «бросаться в воду».

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

Репликация: База Знаний «Заказных Информ Систем» → «Централизация управления на основе интеграции ИТ — один из актуальных трендов в банках»

«Мы видим тренды расширения сферы заказной разработки»

2014-10-14T15:17:18Z

AlexandraVelyaninova:

Игорь Беспальчук, наш руководитель отдела технологического развития, рассказал порталу «Содействие» о специфике и преимуществах заказной разработки, вариантах технической поддержки и дальнейшего развития разработанных систем, а также способах поддержания высокого уровня качества услуг компании. Подробнее читайте в интервью с Игорем «Мы видим тренды расширения сферы заказной разработки».

«Содействие»: Игорь, я хотел бы начать наш разговор с вопроса о преимуществах заказных работ по сравнению с разработками внутри компании. Когда вы встречаетесь с потенциальным клиентом, как вы описываете преимущества вашего подхода?

И. Беспальчук: Когда мы говорим о заказной разработке, мы отделяем её от того, что называется «коробочным» продуктом, и от того, что называется «in-house». Ваш вопрос про второе различение. Если вы имеете дело с большим предприятием, с большой информационной системой, с серьёзным тяжёлым проектом, то разработка бывает весьма непростым делом. Даже не столько сама разработка, сколько организация большого коллектива, управление им, выдерживание долгосрочных аспектов качества, выстраивание процессов, которые помогут вам это качество в дальнейшем поддержать. В in-house это всё тоже можно сделать. Есть много примеров, когда в in-house это сделано, и сделано так, что позавидовать можно. В больших компаниях с многолетней историей это вполне нормальный вариант. Но часто бывает, что компания хочет уделять больше внимания собственному бизнесу, его логике развития и собирать большой штат и заниматься выстраиванием системы производства нет возможностей. В этой ситуации есть смысл обратиться к профессионалам. Почему люди не делают всё сами? Потому что профессионалы сделают лучше. Здесь работает тот же принцип.

«Содействие»: Но всё же — что обходится заказчику дороже или дешевле?

И. Беспальчук: Сложно оценивать такого масштаба вещи, что совокупно дешевле или дороже. Всё, что вы делаете сами, особенно в моменте, окажется дешевле. Но непонятно, как можно сравнивать стоимость суммарной разработки в масштабе 10 лет, например.

«Содействие»: А такой критерий, как стоимость владения?

И. Беспальчук: Он есть, о нём много говорят, но покажите мне того, кто смог его хоть раз посчитать адекватно. А главное — с чем его сравнивать, если системы уникальны? Невозможно вернуться на 10 лет назад и попробовать решить ту же задачу другим способом, а потом сравнить. Если взять банковские системы, которые более стандартизованы, то по стоимости всегда выигрывает коробочный продукт благодаря эффекту масштаба. Он всегда будет дешевле. Но как только вы отходите от чего-то стандартного и вам нужно создать информационную систему под ваши процессы, под ваш особенный бизнес, вы сталкиваетесь с необходимостью разработать что-то новое, стоимость предсказать гораздо сложнее.

«Содействие»: Используете ли вы в ваших разработках в качестве основы собственные «коробочные» продукты?

И. Беспальчук: У нас есть опыт создания малотиражных информационных систем, например биллинговой системы для ЖКХ. Она внедрена в нескольких регионах Российской Федерации в достаточно крупных городах и служит информационным ядром для ЕИРКЦ. В некотором смысле ее можно считать коробочным продуктом.

И все же основная наша специализация — это именно заказная разработка. Но это не значит, что мы каждую систему делаем с нуля. Когда мы подходим к абсолютно новой для нас задаче, мы заинтересованы в том, чтобы сделать это наименьшими усилиями, поэтому стремимся наработки и технологии как на уровне проектных концепций, так и на уровне реализаций в виде кодов и библиотек накапливать и организовывать для дальнейшего использования.

«Содействие»: Несколько лет назад для больших компаний было очень популярно формализовывать свой накопленный опыт, чтобы новый персонал мог получать доступ к наработкам компании. На это тратились достаточно большие деньги. У вас существует формализованная база знаний?

И. Беспальчук: Это не просто база знаний. Я бы назвал это инженерным арсеналом. Знания — часть этого инженерного арсенала. Методики, коды. Мы стараемся всё это формализовать. Наиболее развитый опыт в этой сфере у нас касается методологии учёта. Изначально мы специализировались на учётных системах. Это не принципиальное стратегическое ограничение, но на текущий момент это наша основная специализация. За много лет мы не только накопили инженерно-технологический опыт, но и разработали методологию проектирования учётных систем. На эту тему у нас разработан внутренний учебный курс, и мы обязательно читаем его новым сотрудникам — аналитикам, ведущим разработчикам, архитекторам. Это и отличает профессионалов — багаж знаний и опыта, и — обязательно — коллекция собранных «граблей».

«Содействие»: Есть ли у вас предпочтения в выборе направлений разработок, сферы, в которых вы считаете себя лучшими?

И. Беспальчук: На текущий момент это проектирование, разработка и сопровождение на полном жизненном цикле учётно-аналитических систем. Учёт мы трактуем максимально широко — это и бухгалтерский, и финансовый, и управленческий учет, это может быть учет товародвижения и даже радиоактивных отходов. Тема учёта охватывает большой спектр отраслей — банки, ритейлеры, ЖКХ, госсектор…

«Содействие»: Кто в дальнейшем ведёт сопровождение — обученные люди заказчика или саппорт привязан к вам?

И. Беспальчук: Это зависит от того, как заказчик захочет выстроить наше взаимодействие. Госструктуры и банки хотят полностью отвечать за функционирование системы и быть способными её сопровождать самостоятельно. В этом случае производится обучение по сопровождению их специалистов, их горячей линии, первого эшелона, второго — и так далее. В любом случае мы всегда остаёмся рядом, пока длится наше партнёрство, а мы ориентируемся на долгосрочные отношения. В других ситуациях с другими клиентами нет таких ограничений, и третья линия техподдержки, которая работает достаточно регулярно, — на нашей стороне. Наши специалисты, участвовавшие в разработке этой системы или очень близко связанные с разработчиками, осуществляют ежедневный мониторинг и диагностику работы системы. В больших проектах, о которых мы говорим, и в случае нестандартных систем ее развитие не останавливается в момент сдачи. Система развивается очень интенсивно с момента ввода в эксплуатацию. После того как система разработана и введена в эксплуатацию, дальнейшее её развитие в течение долгих лет приводит к «нарастанию» функционала, которого становится в несколько раз больше, чем было вначале: может происходить декомпозиция систем, интеграция с другими системами на стороне заказчика и т. д. Система растёт и развивается, и мы её холим и лелеем с обеих сторон: со стороны заказчика и с нашей стороны. В этом — суть долгосрочного партнёрства на живом информационно-техническом объекте.

«Содействие»: А заказчик имеет право по условиям контракта самостоятельно развивать систему? Кому принадлежат коды?

И. Беспальчук: Мы всегда оставляем заказчику право и возможность самостоятельно развивать систему. Как правило, коды и вообще всё, что было разработано по требованию заказчика, принадлежит ему. Хотя могут быть и более сложные схемы лицензирования, если использовались существующие наработки. Важно изначально договориться с клиентом о вариантах дальнейшего развития системы. У нас есть опыт, когда заказчик самостоятельно разрабатывает фрагменты системы, через специальные «точки расширения» дорабатывает отчеты или что-то подобное. В таких случаях мы просто договариваемся об интерфейсах взаимодействия. Заказчик знает, что у него есть определённые механизмы, и он может самостоятельно дорабатывать систему. Но он не может в любой момент влезть в любое место системы и что-то там подправить. Это гораздо сложнее организовать, и в нашей практике пока такого не было. Но кто знает, с чем мы столкнёмся в следующий раз и как придётся выстраивать совместную работу. Мы стараемся действовать гибко, ориентируясь на ситуацию заказчика, которая всегда уникальна.

«Содействие»: Резюмируя сказанное вами: заказчик не является привязанным к вам, поручив вам разработку и получив готовый продукт. В принципе, он может самостоятельно в дальнейшем развивать созданную систему.

И. Беспальчук: У нас был опыт, когда мы передавали клиентам технологии разработки и прекращали партнёрство, а их системы продолжали развиваться. Так было, например, в нескольких банках, где клиенты полностью забирали себе сопровождение и развитие АБС, и с системами для ЖКХ, когда организовывалось предприятие ЕИРКЦ и технический центр рядом с ним. Мы организовывали этот технический центр, обучали людей, передавали туда технологии, по которым была построена система, и, если наше партнёрство прекращалось, технический центр продолжал развитие этой системы.

«Содействие»: Любой программный продукт имеет определённый жизненный цикл. Как это происходит в вашей практике?

И. Беспальчук: Есть аналитик или группа аналитиков, которые проводят исследование, пишется анализ клиентской ситуации, задачи информационного IT-ландшафта, с которым предстоит интеграция, или замена существующих систем. Производится концептуальное проектирование, и мы предпочитаем, чтобы оно осуществлялось совместно с представителями заказчика. Со стороны заказчика обычно есть люди, которые компетентны в этих вопросах, — те или иные представители IT-службы или управленцы, хорошо понимающие задачу, и они могут участвовать в её структуризации, или, как минимум, в верификации этого концептуального проекта. После этого формируется проектная команда. Обозначается некая веха, нередко — в долгосрочной перспективе. Мы демонстрируем промежуточные результаты, идёт параллельное детализированное проектирование отдельных фрагментов системы, проводятся интервью с соответствующими специалистами и руководителями и идёт разработка того, что уже проанализировано, с последующей демонстрацией компетентным представителям заказчика. Уже на этом этапе, когда эксплуатации продукта зачастую ещё нет, мы стараемся плотно взаимодействовать с заказчиком. После этого происходит фаза внедрения. После внедрения начинается эксплуатация, связанная с поддержкой и диагностикой системы. Растут объёмы данных, растут масштабы использования, и вместе с ними идет процесс изменения потребностей заказчика. Мы говорим о динамично развивающемся бизнесе, о лидерах рынка, о каких-то нестандартных процессах. Это отличается от ситуации, когда изменения вызваны регламентированными государственными положениями и постановлениями: там есть предсказуемость. Хотя нестабильность принимает другую форму: принято новое постановление — и срочно нужно вносить корректировки к определённой дате. В случае же, когда мы работаем с коммерческими предприятиями и информационными системами, обслуживающими какой-то бизнес, мы сталкиваемся с другой ситуацией. Там всегда кипит мысль предпринимателя, он каждый день придумывает что-то новое, и на это необходимо реагировать.

«Содействие»: Правильно ли я понимаю, что тот период, который характерен для коробочного продукта, когда продукт начинает устаревать, у вас либо растягивается, либо вообще не наступает?

И. Беспальчук: Он растягивается. Он всё же наступает, но сильно растягивается по времени. Устаревают концепции, заложенные очень глубоко в продукт. Устаревает технология. Иногда с этим удаётся справиться более-менее плавно, а бывает так, что систему приходится переделывать целиком. Случается также, что бизнес меняется самым радикальным образом. В таком случае старая система максимально адаптируется к новым условиям и проводится реинжиниринг.

«Содействие»: А как у вас решается вопрос с качеством кода? Как обстоят дела с соответствием каким-то общим и внутренним стандартам?

И. Беспальчук: Когда мы говорим о заказной разработке, нужно рассматривать не только качество кода, но и качество услуги в целом. Качество кода может быть хорошим, а остальные аспекты услуги могут не отвечать поставленным заказчиком задачам. У нас есть внутренние стандарты качества и процессы, направленные на его обеспечение, — Code Review, автоматизированное и ручное тестирования и т. д. Если же говорить о стандартах — мы их знаем и стараемся соответствовать тем требованиям, которые предписываются признанными методологиями разработки ПО. Хотя мы никогда не проводили официальных оценок по методикам CMMI, ключевым требованиям третьего уровня мы соответствуем. Говоря о качестве, сложно опираться только на стандарты. Качество — всегда ответ на представления потребителя о качестве, а эти представления нестандартны.

«Содействие»: Сталкивались ли вы с сопротивлением персонала заказчика во время внедрения ваших систем?

И. Беспальчук: Серьёзных проблем с этим не припоминаю. Работая с позиции заказной разработки, мы находимся на шаг дальше от конечного пользователя, чем в случае с in-house-разработкой, или в сравнении с представителями заказчика, непосредственно работающими с пользователями. Возможно, они как-то экранируют негативную реакцию конечного пользователя и преодолевают его сопротивление. Нам в любом случае ценна обратная связь, и у нас есть практика: каждый член проектной команды должен побывать у непосредственного заказчика и посмотреть на тех людей, которые будут пользоваться нашим программным продуктом. Порой это оказывает удивительное воздействие на разработчиков и на их отношение к работе.

«Содействие»: Любая учётная система делает некие процессы прозрачными, но иногда люди не заинтересованы в прозрачности, поскольку учёт может показать объём их персонального вклада в процессы. Некоторые системы не могли быть внедрены только из-за человеческого фактора.

И. Беспальчук: Обратную связь мы ценим, но ощущения сопротивления у нас не было. Если наш заказчик понимает, что проблема — исключительно в эмоциональной сфере, то эта проблема выпадает из сферы нашего с ним партнёрства.

«Содействие»: Какие тренды вы наблюдаете в России? Как обстоят дела с заказными разработками?

И. Беспальчук: Объём заказных разработок не будет сокращаться. Он может лишь расти, потому что объёмы автоматизации различных отраслей далеко не исчерпаны, и применение коробочных продуктов возможно лишь в случае, когда деятельность сильно стандартизована, а это не может произойти быстро. Мы видим тренды расширения сферы заказной разработки.

Репликация: База Знаний «Заказных Информ Систем» → ««Мы видим тренды расширения сферы заказной разработки»»

Пиджак не застегивается (об интеграции банковских IT)

2014-10-14T14:42:58Z

OlgaChekhunova:

На портале Bankir.ru опубликованы комментарии нашего первого заместителя генерального директора Сергея Тихомирова об интеграции банковских IT. Часто ли приходится адаптировать промышленное решение к конкретным нуждам банка? Какие проблемы обычно возникают при интеграции различных решений? Сколько времени занимает интеграционный проект и есть ли дефицит интеграторов-профессионалов на рынке труда? Ответы на эти и другие вопросы — в материале «Пиджак не застегивается».

Bankir.ru: Часто ли вам приходится своими силами адаптировать промышленное решение к конкретным нуждам банка? Легко ли это? Есть ли практический и экономический смысл в такой «работе напильником»? Или проще сразу сделать «самописное» решение? Как интегрируются промышленные разработки с «самописными»? и часто ли бывает, когда по заказу бизнес-подразделений банковские «айтишники» работают в авральном режиме, а потом это оказывается не столь нужным и не используется максимально или «микроскопом забиваются гвозди»?

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

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

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

Что касается интеграции промышленных разработок с «самописными», то здесь нет никаких особенностей: в какую систему легче внести изменения, необходимые для интеграции, — ту и меняем. Естественно, в большинстве случаев проще всего доработать инхаусную систему.

Наличие или отсутствие «ненужных» доработок (как и любых других изменений) зависит в первую очередь от зрелости организации (банка) — в частности, от того, насколько эффективно в ней выстроен процесс управления изменениями.

Bankir.ru: Сейчас рынок заказчика и время построения компонентной архитектуры — у кого-то с нуля, у кого-то — «смесь бульдога с носорогом». Насколько для интеграции IT-решений от разных поставщиков характерна поговорка «К качеству пуговиц претензий нет, но пиджак не застегивается»? Какие проблемы обычно возникают при интеграции? Есть ли контакт и уступки разработчиков при решении интеграционных проблем отдельного банка-заказчика?

С. Тихомиров: Пока построение компонентной архитектуры — это новое веяние, и у нас нет информации о хоть сколько-нибудь значимом числе кредитных организаций, успешно завершивших этот процесс.

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

Если под «пуговицами» понимать компоненты, а под «пиджаком» — IT-ландшафт в целом, то в случае стихийного внедрения без концепции и плана никто не отвечает за качество этого самого «целого».

Налаживание эффективного взаимодействия между заказчиком и подрядчиком — актуальный вопрос не только для банков и не только для интеграционных проектов, а для всей сферы IT-услуг. Все зависит от взаимной заинтересованности и умения работать в модели партнерства, основанной на равенстве обеих сторон, доверии и уважении.

Bankir.ru: Имеет ли банк собственных интеграторов в штате или использует только аутсорсинг? Если в команде есть и штатные интеграторы и приглашенные, то не возникает ли конфликта интересов? Сколько времени занимает интеграционный проект и «выживает» ли при этом команда или в процессе может замениться? Чувствуется ли дефицит интеграторов-профессионалов на рынке труда?

С. Тихомиров: Интеграционный проект — не инфраструктурный, а ключевой для банка. Поэтому такого, чтобы в банке вообще не было собственных специалистов по интеграции, я не видел. Это слишком рискованно — полностью полагаться на аутсорсинг, чаще всего такие проекты отдаются на частичный внешний подряд.

Наличие конфликтов интересов, опять-таки, зависит от зрелости процессов управления: если организации нет, в проекте царит хаос, то может возникнуть и конфликт интересов, и вообще что угодно, и объем последствий будет пропорционален масштабу затеянных изменений.

Конечно, это длительные проекты, ведь они подразумевают изменение информационной архитектуры банка и отдельных компонентов IT-ландшафта. Риск, что команда распадется, уйдет и заберет с собой ключевые знания и компетенции, — самый серьезный, и банки обычно делают все, чтобы этого не случилось.

Профессионалов в принципе не хватает, и это касается не только интеграторов и даже не только IT-сферы, но и всего рынка труда.

Репликация: База Знаний «Заказных Информ Систем» → «Пиджак не застегивается (об интеграции банковских IT)»

Лихорадка ЦОДостроительства еще не наступила

2014-10-13T15:52:12Z

OlgaChekhunova:

На портале CNews опубликованы комментарии ведущего системного инженера Дмитрия Морозова к статье «Лихорадка ЦОДостроительства еще не наступила». Каковы перспективы строительства ЦОДов в регионах? Окажет ли на рынок положительное влияние открытие представительства Uptime Institute в России? На что ориентируются заказчики, заказывая строительство ЦОД? Об этом — в материале Дмитрия Морозова.

CNews: В России на конец 2012 года насчитывалось порядка 170 крупных и средних коммерческих центров обработки данных, причем более 100 из них — в московском регионе и около 40 — в Санкт-Петербурге и Ленинградской области. Таким образом, 60 % площадей на сегодняшний день обеспечивают Москва и Московская область. Привлекательны ли регионы для строительства ЦОД?

Д. Морозов: Если в крупных российских городах каналы связи высокого качества, то в провинции связь (как и пресловутые «дороги») позволяет желать лучшего. Именно отсутствие высокоскоростных и надежных каналов связи является основным тормозящим фактором для строительства ЦОД в регионах. Кроме того, концентрация квалифицированных специалистов значительно выше в столицах и крупных городах.

По-видимому, тенденция строительства ЦОД в больших городах в ближайшем будущем останется, поскольку задача прокладки широких и надежных каналов связи в регионах решается крайне медленно. С другой стороны, нельзя не заметить, что именно регионы являются очень привлекательными для строительства ЦОД. Это и дешевая аренда площадей, и прямой доступ к поставщикам электроэнергии. Северным районам дополнительную привлекательность придают низкие затраты на охлаждение. Например, в прессе появилось сообщение, что Альфа-Банк планирует разместить ЦОД «где-то за Уралом».

CNews: Российские компании в силу высокой стоимости сертификации Uptime Institute предпочитают говорить о своем фактическом соответствии TIER III, не проходя сертификацию. Окажет ли на рынок положительное влияние открытие представительства Uptime Institute в России?

Д. Морозов: Ключевые факторы, тормозящие переход компаний в коммерческие ЦОД, — это отсутствие гарантий безопасности размещения данных — как от потерь, так и от утечек информации. Если посмотреть статистику по публичным ЦОД, то меньше всего их используют финансовые организации, медицинские учреждения, операторы персональных данных… В целом, на данный момент публичные ЦОД пока плохо подходят для организаций, обрабатывающих информацию ограниченного доступа. Решение этой проблемы будет приоритетной задачей для провайдеров в ближайшее время.

Практически все арендаторы ЦОД, не нуждающиеся в особой защите данных, уже «поделены» между провайдерами. В «войне» за держателей информации ограниченного доступа важным преимуществом провайдеров будет соответствие требованиям Uptime Institute, потому ожидается рост количества сертифицированных ЦОД.

CNews: Основным потребителем услуг ЦОД (более 40 %) является финансовый рынок. На что ориентируются заказчики, заказывая строительство ЦОД?

Д. Морозов: Для финансового сектора наиболее актуальна проблема нехватки серверных площадей и энергетических мощностей. Решение по размещению на арендуемой площадке или строительстве собственных ЦОД принимается для каждого отдельного случая, но большинство финансовых организаций предпочитает хранить и обрабатывать данные в собственных ЦОД. Связано это с тем, что на сегодняшний день отечественным банкам сложно найти поставщика, который бы соответствовал их требованиям по безопасности и надежности. Так, например, свои ЦОД имеют и Сбербанк, и ВТБ24, и Альфа-Банк. А вот один из крупнейших на Украине банков Райффайзен Банк Аваль пошел по другому пути, и арендует ресурсы ЦОД у украинского же провайдера.

Репликация: База Знаний «Заказных Информ Систем» → «Лихорадка ЦОДостроительства еще не наступила»

Сервисы в ЦОДе: жизнь за рамками colocation

2014-10-13T14:16:09Z

OlgaChekhunova:

В журнале «ИнформКурьер-Связь» опубликованы комментарии ведущего системного инженера Дмитрия Морозова о ситуации на российском рынке дата-центров. Каковы прогнозы экспертов отрасли о развитии рынка? Как должно быть построено взаимодействие между клиентом и провайдером сервисов дата-центра? Как меняются требования клиентов к надежности услуг? Об этом — в комментариях к материалам «Uptime Institute — отличный бизнес-проект, нацеленный на коммерциализацию стандартов» и «Привести инженерное хозяйство ЦОДа в порядок сложнее, чем построить новый объект».

«ИнформКурьер-Связь»: Как, по вашему мнению, должно быть построено взаимодействие между клиентом и провайдером сервисов дата-центра? Что сейчас хотят получить клиенты (гибкий индивидуальный подход, четкое выполнение всех формально прописанных процедур, само наличие свода процедур и правил)? Какой, по вашему мнению, должна быть система оплаты ресурсов и сервисов в дата-центрах?

Д. Морозов: Перевод данных в коммерческий дата-центр — это не только техническая, но и организационная задача. Если техническая основа современных ЦОД — виртуализация, то концептуальная основа — это стратегия «ИТ как услуга». Соответственно, речь идет о смене парадигмы и переходе к сервисному подходу в управлении ИТ компании-заказчика. Техническая сторона процесса перехода в коммерческий ЦОД или публичное облако достаточно хорошо стандартизирована, а вот организационная — сугубо специфична для каждой компании.

Заказчики, которые заботятся об уникальности своих бизнес-процессов, заинтересованы в гибком индивидуальном подходе. Чтобы подобрать оптимальные характеристики используемых сервисов ЦОД, необходимо сначала на уровне бизнес-требований определить формы предоставления сервисов и согласовать уровни их оказания (SLA). Только после этого ИТ-служба заказчика может оценить потребности компании в ИТ-сервисах и согласовать условия их предоставления с провайдером. Далее эти условия будут постоянно уточняться по мере изменения потребностей бизнеса. Таким образом, переход к облачным технологиям — сложный проект на стыке бизнеса и ИТ.

«ИнформКурьер-Связь»: Ваши прогнозы на развитие ситуации на российском рынке услуг дата-центров? Как, по вашему мнению, будут меняться требования клиентов к надежности дата-центров, к доступности данных и приложений, к номенклатуре сервисов, предлагаемым в ЦОДах, к службе поддержки клиентов? Что могло бы, на ваш взгляд, способствовать росту доли высокоуровневых сервисов дата-центров?

Д. Морозов: При передаче сервисов в коммерческий ЦОД возникает вопрос об ответственности провайдера за простои бизнес-процессов заказчика из-за сбоев в работе ЦОД. Но на данный момент лишь немногие поставщики готовы взять на себя финансовую компенсацию потерь клиентов. Цивилизованным выходом из ситуации было бы страхование таких рисков, но пока на российском рынке не существует подобных предложений.

В последние годы наблюдается ЦОДостроительный бум. При этом всё больше ЦОДов размещаются в специально построенных для них зданиях (с системами гарантированного питания и кондиционирования). Большая часть ЦОД (более 80 %) располагаются в Москве и в Санкт-Петербурге — регионах с хорошо развитыми коммуникационными сетями. Если техническим характеристикам (таким как пропускная способность канала до ЦОД, наличие вычислительных и энергетических мощностей) соответствует большинство крупных провайдеров, то в вопросах, связанных с менеджментом в ИТ, нередко возникают сложности. Особенность услуги, предоставляемой ЦОД, заключается в том, что ее качество зависит от мастерства управления ИТ как на стороне провайдера, так и на стороне заказчика, а главное — от их слаженного взаимодействия.

«ИнформКурьер-Связь»: Актуальны ли для российских дата-центров услуги аудита инженерной и ИТ-инфраструктуры и аудита службы эксплуатации? Некоторые российские дата-центры заявили о планах сертификации своих систем эксплуатации в Uptime Institute (Operational Sustainability). Кроме того, недавно Uptime Institute запустил программу аудита систем эксплуатации дата-центров (Management and Operations). Повлияет ли это на уровень надежности работы российских ЦОДов?

Д. Морозов: Конкуренция на рынке облачных услуг усиливается, в то время как количество компаний, которые еще не перевели свои системы в облака (публичные или частные), стремительно сокращается. Потому, в первую очередь, сертификация нужна ЦОД для предоставления своим клиентам гарантий качества услуг и сохранности их данных.

Таким образом, естественной причиной роста уровня надежности работы российских ЦОД является усиление конкуренции на рынке. А необходимость независимой экспертизы для объективного подтверждения достигнутого уровня обслуживания увеличивает важность аудита и сертификации.

Репликация: База Знаний «Заказных Информ Систем» → «Сервисы в ЦОДе: жизнь за рамками colocation»

Тотальный контроль или безграничное доверие?

2014-09-10T13:18:11Z

AlexandraVelyaninova:

Евгения Удалова, наш руководитель отдела персонала, дала комментарий к статье в Intelligent Enterprise о контроле за рабочим временем сотрудников. Можно ли совместить учет и контроль с доверием и самоорганизацией? Какие плюсы дает подобный «гибридный» подход? И как «взять больше» от классических инструментов контроля, таких как СКД, система учета времени и хронометраж рабочего дня? Об этом — в комментарии к статье «Под колпаком» на сайте издания.

Вопрос о принципиальном выборе одной из двух противостоящих парадигм менеджмента — научной организации труда или принципов «открытой компании» — все еще актуален для многих организаций. И хотя тотальный учет и контроль рабочего времени сотрудников, как правило, ассоциируется с погоней за механистическим ростом производительности труда, в то время как доверие и самоорганизация, как предполагается, повышают эффективность работы благодаря ее осмысленности и вовлеченности персонала, многие современные компании пытаются, причем достаточно успешно, совместить эти два подхода.

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

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

Таким образом, нельзя утверждать, что система научной организации труда безнадежно устарела: при грамотном использовании ее инструменты можно поставить на службу профессионалу.

Возьмем, к примеру, СКД (систему контроля доступа). «Контрол-фрик» организации устанавливают СКД, чтобы выявлять, чем конкретный сотрудник занят в каждый момент времени, и в случае «недопустимого» поведения осуществлять «корректирующее воздействие» (делать замечания, предупреждения). На мой взгляд, такой результат не оправдывает затрат на внедрение и сопровождение системы. Однако СКД можно рассматривать и как источник информации о перемещении сотрудников по офису, которая позволит осуществить грамотное перепроектирование офисного пространства (опять же, с целью сокращения непродуктивного времени): поиск более удачного расположения переговорных комнат, мест для кулеров или принтеров, выделение помещений для работы временных рабочих/проектных групп или мини-складов для служб АХО.

Что касается автоматических систем учета времени (таких, как упомянутая CrocoTime), то их использование в крупных компаниях и (или) для тех видов деятельности, которые предполагают высокий уровень нормирования и стандартизации, безусловно, целесообразно. Но мне видятся существенные ограничения на применение таких систем для позиций с ненормированным рабочим днем (почту можно проверить утром в транспорте с мобильного устройства), при большом объеме коллективного труда (мозговые штурмы, работа с досками и другими средствами визуализации), для работы на территории клиента, для управленческих позиций. И здесь уместно задать вопрос: кто приносит компании наибольшую пользу? И, следовательно, на какую категорию персонала должно быть направлено максимальное внимание? Возможно, вопрос эффективности линейных руководителей и ключевых сотрудников, оптимальной структуры их работы, позволяющей восстанавливаться и препятствовать выгоранию, приносит ощутимо больший результат, чем реализация программы учета и контроля рабочего времени всего персонала компании.

Наконец, скажу пару слов о хронометраже рабочего дня, который в управлении выродился в ежедневные (или еженедельные) отчеты с детальным описанием того, чем занимался сотрудник. Этот инструмент можно с пользой применять для диагностики с целью будущего анализа. В противном случае его ценность очень быстро нивелируется — появляется шаблон, который чуть-чуть корректируется изо дня в день. А главное, что при таком подходе задача по анализу продуктивности работы (по сути, по проведению рефлексии) ложится на руководителя, а не на самого сотрудника.

Вообще я глубоко убеждена, что осмысленность работы и заинтересованность дают существенно больший вклад в результат любой деятельности, а подсматривание и подглядывание за своим персоналом — удел не профессиональных управленцев, а недалеких администраторов. Но, учитывая прогнозы теории поколений о том, какой персонал выйдет на рынок труда через 5–10 лет, я соглашусь с предположением, что его жизнь в ближайшем будущем станет для руководства еще более прозрачной. И причина кроется не в растущей паранойе руководителей, а в том, что, с одной стороны, общество будет готово это принять, а с другой — такой подход к управлению будет компенсировать ряд слабых сторон самих сотрудников нового поколения.

Репликация: База Знаний «Заказных Информ Систем» → «Тотальный контроль или безграничное доверие?»

Система мониторинга должна быть независимой

2014-09-10T13:16:14Z

AlexandraVelyaninova:

Сергей Тихомиров, первый заместитель генерального директора, рассказал «Банковскому обозрению» о различных подходах к мониторингу бизнес-процессов. Как определить качество исполнения бизнес-процессов? Чем тактико-стратегический мониторинг отличается от оперативного? Всегда ли эффективны BPM-системы? Об этом — в интервью с Сергеем на сайте и в бумажной версии журнала.

Мониторинг бизнес-процессов — проверенное средство повышения эффективности деятельности компаний с большим количеством сквозных бизнес-процессов, в частности банков. О подходе, который позволяет осуществлять мониторинг не только функционирования, но и развития финансово-кредитных организаций, «Б.О» рассказал Сергей Тихомиров, первый заместитель генерального директора группы компаний CUSTIS.

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

Сергей Тихомиров: Тема мониторинга и управления, основанного на его данных, не нова и в последние годы действительно приобретает все большую актуальность. Это связано с постоянным увеличением системной сложности — как самого бизнеса, так и IT — и высокой динамикой изменений в крупных компаниях. Поэтому функции, которые позволяют следить за стабильностью работы систем и гарантируют качественное исполнение бизнес-процессов, становятся необходимыми для эффективной работы современных финансовых организаций.

«Б.О»: Каким образом можно определить качество исполнения бизнес-процессов?

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

«Б.О»: А как вы получаете показатели, на основании которых делаются выводы об эффективности?

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

Если из существующих журналов невозможно получить необходимую информацию, то, как правило, журналы событий IT-систем клиента дорабатываются. Для получения информации о неавтоматизированных операциях возможна «эмуляция» проведения таких операций, то есть ручной ввод данных о них непосредственно в систему мониторинга. Этот способ достаточно неудобный и затратный, но бывает, что он оправдан для задач оптимизации.

Далее, чтобы приблизиться к задаче оптимизации, необходимо выявлять и анализировать значения показателей, которые критически влияют на эффективность. С помощью аналитического подхода к мониторингу можно не только наблюдать реальную картину исполнения бизнес-процессов, но и обнаруживать закономерности, снижающие эффективность, — так называемые «точки неэффективности». От того, насколько удачно определены параметры модели, зависит качество полученных результатов, а значит, успех организации в целом.

«Б.О»: А если модель спроектирована не вполне корректно? Как это определить?

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

Доработка и оптимизация модели бизнес-процессов носит не разовый характер. Деятельность крупной компании постоянно развивается: меняется рынок, меняются требования клиентов, — и все это требует постоянных изменений и корректировок бизнес-процессов. Важным преимуществом является способность системы быстро и гибко подстраиваться под любые изменения, не затрагивая IT-ландшафт организации.

«Б.О»: Мы много поговорили про мониторинг текущей деятельности. А как можно с помощью мониторинга влиять на развитие компании?

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

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

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

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

«Б.О»: Отличается ли подход к мониторингу текущей деятельности от подхода, направленного на долгосрочные перспективы компании?

Сергей Тихомиров: Безусловно. Чтобы отслеживать функционирование, достаточно настроить соответствующие стандартные показатели в зависимости от поставленных задач. Если мы говорим о мониторинге, направленном на развитие, то стандартных показателей здесь практически не существует и в зависимости от целей бизнеса модель показателей необходимо каждый раз создавать и улучшать.

«Б.О»: Существуют системы управления бизнес-процессами — BPM-системы, — в которых эти процессы можно просто реализовывать. Если отслеживать процессы в системе BPM, то непонятно, зачем нужна внешняя система мониторинга.

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

Репликация: База Знаний «Заказных Информ Систем» → «Система мониторинга должна быть независимой»

Управление изменениями как основа конкурентного преимущества

2014-09-09T15:33:48Z

AlexandraVelyaninova:

Сергей Ефанов, руководитель направления «Банковские учетные системы», и Олег Малышев, аналитик-эксперт в банковской сфере, рассказали «Национальному банковскому журналу» о сущности и причинах изменений в современных розничных банках. Как разрешить противоречие между назревшей потребностью в изменениях и необходимостью бесперебойной работы банка? Какую роль играет в этом процессе информационная архитектура? Что препятствует полноценному управлению изменениями и как построить «технологичную» систему их проведения? Об этом — в статье «Управление изменениями как основа конкурентного преимущества» на сайте и в бумажной версии журнала.

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

Сокращение рынка серверов в EMEA в 2011–2013 гг.

2014-09-05T08:49:34Z

AlenaKolyaseva:

Дмитрий Морозов, ведущий системный инженер нашей компании, рассказал IT Weekly о текущей тенденции сокращения рынка серверов и ее причинах. О роли в этом процессе технологических факторов (виртуализации, развития облачных технологий, увеличения срока амортизации серверов) — в статье «IDC: рынок серверов в EMEA уменьшается шестой квартал подряд» на сайте еженедельника.

Кроме общемировой кризисной экономической обстановки, на сокращении рынка серверов сказываются и чисто технологические факторы, такие как виртуализация и консолидация серверных мощностей.

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

Например, в центре обработки данных нашей компании для одного из проектов использовались четыре серверные стойки. После переноса в виртуальную среду все серверы проекта (с тем же уровнем резервирования) занимают всего одну стойку. Что, кроме экономии места в ЦОД, привело к сокращению потребления электроэнергии (с 20 до 6 кВт) и снижению мощности кондиционеров (с 17 до 7 кВт). Такой эффект от применения виртуализации (наряду с увеличением масштабируемости и управляемости) делает эту технологию все более популярной. Например, VMware прогнозирует ежегодный рост рынка виртуализации на 20% до 2016 года.

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

Кроме того, вопреки PR-заявлениям производителей, заметно снижение темпов роста процессорных платформ. Если еще 3–4 года назад срок амортизации серверов составлял 2–3 года, то сейчас он увеличивается до 3–5 лет (более частая замена оборудования уже нерентабельна, поскольку прирост производительности не столь значителен). Естественно, этот факт также негативно влияет на рост рынка серверных мощностей.

Репликация: База Знаний «Заказных Информ Систем» → «Сокращение рынка серверов в EMEA в 2011–2013 гг.»

Облачная инфраструктура ЦОД: готовность оператора и заказчика

2014-09-04T11:06:31Z

AlenaKolyaseva:

Дмитрий Морозов, ведущий системный инженер нашей компании, рассказал журналу «Технологии и средства связи» об основных задачах провайдеров облачных услуг и о том, что необходимо учитывать организации при переходе к облачным технологиям. Пояснения Дмитрия опубликованы на сайте и в бумажной версии журнала.

«Технологии и средства связи»: С какими проблемами сталкивается оператор при предоставлении серверных мощностей облачного ЦОД своим заказчикам?

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

«Технологии и средства связи»: Какие требования предъявляют к оператору облачного ЦОД потенциальные клиенты?

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

«Технологии и средства связи»: Что необходимо заказчику для трансформации своей IT-инфраструктуры для перехода в облако?

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

«Технологии и средства связи»: Что мешает более активному переходу заказчиков к облачным технологиям?

Д. Морозов: Ключевые факторы, тормозящие переход компаний в облака, — это отсутствие гарантий безопасности размещения сервисов в облаке и соответствия действующему законодательству. Меньше всего публичные облака используют финансовые организации, медицинские учреждения, операторы персональных данных… В целом на данный момент публичные облака пока плохо подходят для организаций, обрабатывающих информацию ограниченного доступа. Решение данной проблемы будет приоритетной задачей для провайдеров в ближайшее время.

Репликация: База Знаний «Заказных Информ Систем» → «Облачная инфраструктура ЦОД: готовность оператора и заказчика»

Российский рынок интернет-торговли стал крупнейшим в Восточной Европе

2014-09-04T09:31:03Z

AlexandraVelyaninova:

Алексей Баранов, руководитель интернет-проектов для торговых сетей, рассказал «Российской газете» о состоянии электронной торговли в России и перспективах ее развития. Комментарий Алексея опубликован в материале «Российский рынок интернет-торговли стал крупнейшим в Восточной Европе». Мы публикуем полную версию интервью.

По данным Euromonitor International (EI), российский онлайн-рынок на сегодняшний день является крупнейшим в Восточной Европе. Объем рынка российского интернет-ритейла составляет примерно 10,5 миллиардов долларов.

«Российская газета»: Что, на ваш взгляд, является главными стимулами развития электронной торговли в России?

А. Баранов: Развитие электронной торговли в России связано со следующими факторами:

проникновение Интернета не только в Москве, но и в средних и небольших городах (в настоящий момент 43 % россиян хотя бы раз в сутки выходят в Сеть);

расширение спектра и рост продаж мобильных устройств, позволяющих выходить в Интернет в любом месте и в любое время;

рост доверия к электронной торговле: покупки через Интернет становятся все более привычными;

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

«Российская газета»: Что тормозит развитие рынка?

А. Баранов: Основным тормозом развития интернет-торговли в России является слабо развитая логистическая сеть: «плохие» транспортные связи, в частности, между столицей и регионами, что делает доставку между городами дорогой и длительной.

Кроме того, эффективная электронная торговля требует полного пересмотра подхода к управлению товарным запасом, который существенно отличается от привычной «офлайновой» схемы. Многим интернет-магазинам (в частности, одежды и обуви) критически важно научиться работать с массовыми отказами от товара после примерки (в среднем от купленной в Интернете одежды отказываются 30–50 % покупателей).

«Российская газета»: Каковы перспективы развития рынка?

А. Баранов: Безусловно, в ближайшие годы рынок будет расти, конкретные цифры приводить бессмысленно, поскольку могут произойти не только количественные, но и качественные изменения (например, появление полноценных виртуальных примерочных, изменение «привычки» оплаты наличными и т. д.).

«Российская газета»: Спасибо за беседу.

Репликация: База Знаний «Заказных Информ Систем» → «Российский рынок интернет-торговли стал крупнейшим в Восточной Европе»

Отзыв о книге Донеллы Медоуз «Азбука системного мышления»

2014-09-04T08:56:04Z

OlgaChekhunova:

На портале theRunet.com опубликован отзыв Евгении Удаловой, руководителя отдела персонала нашей компании, о книге Донеллы Медоуз «Азбука системного мышления». О том, чем эта книга может быть полезна для HR-специалистов, работающих в сфере IT, — в материале «4 лучших книги для специалиста по работе с персоналом».

Эта книга, скорее всего, не станет вашей настольной, поскольку вопросы HRM в ней не рассматриваются, но, если вы работаете в IT, прочесть ее нужно обязательно.

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

HR-специалистам важно не просто уметь находить общий язык со своими сотрудниками — зачастую именно от HR’а ждут помощи в налаживании эффективных коммуникаций и выстраивании взаимодействия внутри команды или подразделения. А это значит, что нам с вами нужно уметь общаться на разных уровнях абстракции, замечать логические разрывы и конфликты понятий, держать рамку разговора, отслеживать логику рассуждений собеседника, даже если она явно не проговаривается.

Помню, как в самом начале своей работы в IT меня просто поражало, как быстро люди думают и рассуждают, насколько разносторонне смотрят на обсуждаемые вопросы и эффективно переключаются между разными уровнями абстракции, не позволяя дискуссии скатываться в мелкие детали и незначительные нюансы.

Конечно, эта книга не научит всему и сразу, но она позволит разобраться с понятием «системное мышление», разложить его на составляющие и узнать основные принципы и закономерности. Если удается это «переварить» и отрефлексировать на окружающую действительность (когда вы начинаете видеть и применять то, о чем прочитали), то IT-шники перестают казаться такими уж непонятными, с ними становится интересно общаться, и постепенно это становится взаимным.

Честно говоря, открывая «Азбуку системного мышления», я готовилась к серьезному чтению и совсем не ожидала, что про сложное можно рассказывать так просто, наглядно, а главное — понятно. Немного жалею, что книга не попала ко мне в руки в начале моей карьеры, но и сейчас я нашла в ней много полезного.

Репликация: База Знаний «Заказных Информ Систем» → «Отзыв о книге Донеллы Медоуз «Азбука системного мышления»»

А сало русское едят (о предпочтениях банков в IT)

2014-09-04T08:48:01Z

AlexandraVelyaninova:

Сергей Тихомиров, первый заместитель генерального директора и руководитель направления «Финансовые институты», рассказал порталу «Bankir.Ru» о перспективах развития рынка банковской автоматизации и о том, насколько конкурентноспособны российские IT-решения в сравнении с западными. Комментарии Сергея опубликованы в материале «А сало русское едят». Мы публикуем полную версию интервью.

Bankir.Ru: Предпочтение банков в IT — «покупай российское» или поддержка импорта? Насколько конкурентоспособны российские вендоры в сравнении с транснациональными корпорациями, если речь не идет об IT-решениях, призванных не только генерировать отчетность в соответствии с требованиями регулятора?

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

Стоит отметить, что в разных областях банковской деятельности применимость западных решений различна. Ключевую роль здесь играют три фактора: необходимость и объемы поддержки российской специфики, потребность в современных технологиях и значимость юзабилити и дизайна интерфейса. Если разложить автоматизацию на стандартные слои front — middle — back — accounting, то достаточно очевидно, что во фронт-офисе соответствие западных решений перечисленным требованиям максимально, а с переходом на каждый следующий слой оно падает.

Наша компания в своих решениях для банковской сферы имеет наиболее сильную экспертизу и обширный опыт именно в части back — accounting. В настоящий момент мы предлагаем банкам решение, в основе которого лежит учетно-ориентированная архитектура. Оно позволяет сделать компоненты front — middle и back — accounting максимально независимыми друг от друга.

Что касается локализации и генерации регуляторной отчетности, то здесь российский рынок ничем не отличается от рынка любого другого крупного государства. Например, в США из-за различий в законодательстве разных штатов у крупных компаний возникает необходимость локализации части IT-решений для каждого штата.

Bankir.Ru: По каким причинам банки меняют АБС?

С. Тихомиров: Сейчас замена АСБ целиком может быть обусловлена двумя причинами: серьезными проблемами во взаимоотношениях с подрядчиком или критичными технологическими рисками, связанными с отсталостью технологий. В большинстве же случаев банки стараются переходить к компонентной архитектуре: происходит внедрение новых решений, сопровождающееся выводом части функционала из существующих.

Bankir.Ru: Многие банки заявляют о сокращении IT-расходов. Тенденция такова: купить лучшее решение, но подешевле. Какие вендоры выиграют на этом поле — российские или зарубежные?

С. Тихомиров: В настоящее время западные вендоры осуществляют активную экспансию на российский рынок и заставляют отечественных производителей «потесниться», но в этой тенденции есть изрядная составляющая моды и желания попробовать что-то новое. Я склонен считать, что через 3–5 лет ситуация может снова измениться, но уже в пользу российских компаний, однако для этого им придется серьезно перестроить свою услугу. К необходимости качественного изменения услуг уже подошла значительная часть российских IT-компаний.

Bankir.Ru: Почему мало успешных внедрений западных АБС? Работают ли, на ваш взгляд, западные вендоры на адаптацию к российским реалиям? Банки при замене АБС отказываются от «монолитных» IT-решений, переходят по возможности к компонентной архитектуре — это реальность сегодняшнего дня. Кто займет больше места и принесет больше «строительных кубиков» — российские или зарубежные вендоры?

С. Тихомиров: Внедрений западных решений сейчас не так мало, но они в основном сконцентрированы в сегменте front — middle (причины упоминались выше). В плане адаптации к российскому рынку западные вендоры ведут себя совершенно по-разному. Я думаю, это зависит от того, работают ли они на других развивающихся рынках. Те, кто работает, понимают необходимость локализации, однако значительная часть вендоров не пытается активно адаптироваться для нашей страны. Легко предположить, что в долгосрочной перспективе это будет иметь негативное последствие для их экспансии на российский рынок.

Bankir.Ru: Вендоры говорят, что сейчас «рынок заказчика». Что просят банки? Смотрят ли они вперед и что там видят? Способны ли вендоры предложить рынку «новый взгляд», новый вектор развития, как это было двадцать лет назад, когда все только начиналось в российской автоматизации или работают исключительно на конъюнктуру?

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

Bankir.Ru: Проблема технической зависимости от вендора — на какие уступки вы способны, чтобы выиграть на конкурентном поле? Не смущает ли вас желание банков создавать свои собственные IT-компании? Как воспринимает технические нововведения персонал банков?

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

Bankir.Ru: Каковы ТОП-5 направлений, по которым в ближайшие годы будут развиваться банковские технологии?

С. Тихомиров: Я думаю, что в ближайшее время будут прежде всего развиваться следующие направления:

1) разработка информационной архитектуры;

2) интеграционные решения;

3) интернет-решения;

4) мобильные решения;

5) учетно-аналитические решения.

Bankir.Ru: Спасибо за беседу.

Репликация: База Знаний «Заказных Информ Систем» → «А сало русское едят (о предпочтениях банков в IT)»

Удаленная работа: за и против

2014-09-03T12:21:58Z

AlenaKolyaseva:

На портале «Планета HR» опубликован комментарий Евгении Удаловой, руководителя отдела персонала нашей компании, о преимуществах и недостатках удаленной работы. Поводом к обсуждению стал полный отказ Yahoo от такой формы организации труда и категорическое требование присутствия сотрудников в офисе по расписанию. Насколько оправданна удаленная работа? Почему в нашей компании это только возможность, но не правило? И что мы понимаем под принципом collaboration? Об этом — в материале «Удаленная работа: за и против».

Вопрос удаленной работы в последние годы постоянно встает перед многими компаниями. И главное, что однозначного ответа на него нет.

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

Итак,

компания CUSTIS представляет IT-индустрию, так что вопросы, связанные с гибким подходом к организации труда, для нас совсем не новы;

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

Здесь важно пояснить, что под гибким графиком мы понимаем возможность сотрудника самостоятельно определять время прихода и ухода и планировать свою загрузку в течение недели.

Удаленная работа в нашей компании подразумевает именно возможность взять несколько дней в месяц, чтобы поработать из дома или на даче (что особенно актуально в летнее время).

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

Ответ очень простой, давайте еще раз вдумаемся в эти цифры:

объем знаний в области технических наук удваивается каждые 2 года;

во всех областях человеческой деятельности наблюдается информационный взрыв: по статистике, объем цифровой информации удваивается каждые 18 месяцев, количество блогов в Интернете удваивается каждые 6 месяцев, а число статей на вики-коллаборативных порталах растет экспоненциально;

многие компании уже сейчас пересматривают свои планы раз в 2–3 месяца, что соответствует запросам стремительно меняющейся внешней среды.

Темпы изменений с каждым годом растут, а ведь компании важно не просто сохранить свои позиции на рынке, но и усилить свои конкурентные преимущества.

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

Ответом на такой вызов стал подход collaboration (в переводе — сотрудничество, совместная работа) — а-ля «творческая мастерская», когда акцент в работе группы делается на сущностном, основном, максимальное количество процедур оптимизируется, процессы становятся более демократичными. Например, над проектами документов можно работать во время совещаний, фиксировать мысли схемами на доске, широко использовать инструменты визуализации для создания общего рабочего пространства.

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

И все же решение Yahoo кажется слишком категоричным. Не обязательно совсем отказываться от удаленной работы, ведь такая форма организации труда позволяет решать типовые, стандартные задачи, где можно четко сформулировать постановку задачи и требования к результату. Но конкурентные преимущества редко лежат в области стандартных подходов. Поэтому, внося изменения в схему организации труда, не нужно бояться экспериментировать, сочетать различные формы и пробовать что-то новое — только так вы найдете идеальный вариант.

Репликация: База Знаний «Заказных Информ Систем» → «Удаленная работа: за и против»

Как помочь сотрудникам жить счастливой и здоровой жизнью?

2014-09-03T09:44:14Z

OlgaChekhunova:

На портале «Планета HR» опубликован комментарий руководителя отдела персонала Евгении Удаловой о современных подходах к организации труда. В чем преимущества гибкого графика для компании и ее сотрудников? Как он реализуется? Каких изменений в корпоративной культуре требует внедрение такой практики? Об этом —в комментарии к материалу «Как помочь сотрудникам жить здоровой и счастливой жизнью?» на крупнейшем портале о кадровом рынке.

Ни для кого не секрет, что гибкий график и возможность работать удаленно для IT-индустрии уже давно не тренд, а привычная реальность. Исключения есть, но их мало.

Для нашей компании такой подход к организации работы — это не просто опция, повышающая привлекательность бренда, «приманка» для кандидатов, а, в первую очередь, форма выражения принципов корпоративной культуры.

Мы ценим время своих сотрудников не меньше, чем время клиентов или партнеров. Именно поэтому мы строим рабочий процесс таким образом, чтобы у каждого была возможность:

выбрать оптимальный график работы, определив удобное время прихода и ухода;

произвольно распределить свою загрузку в течение недели: в какой-то день работать больше, в какой-то — меньше;

несколько дней в месяц работать удаленно, например из дома или кафе;

среди недели взять оплачиваемый отгул и выйти на работу в выходной (в нашем офисе комфортные условия работы 24 часа в сутки 7 дней в неделю).

Это позволяет работать в более привычном и удобном режиме: мучительно в 9:00 видеть на работе «сов», которые литрами заливают в себя кофе, а на вечерних совещаниях пытаться обсуждать серьезные вопросы с дремлющими «жаворонками».

Кроме того, такой подход помогает нашим специалистам найти баланс между напряженной работой и личной жизнью, ведь компания с пониманием относится к каждому сотруднику, его проблемам и трудностям, в том числе и за пределами офиса. Заболел ребенок, прорвало трубу, нужно срочно помочь родственникам — у всех случаются внештатные ситуации, когда нужно взять отгул, прийти к обеду или поработать из дома.

Если вы всерьез задумываетесь о том, чтобы внедрить современные формы организации труда, компания должна быть готова изменить в себе гораздо больше, чем правила внутреннего трудового распорядка.

Прежде всего, нужно будет пересмотреть свой взгляд на понятие «дисциплина»: теперь это не работа с 9:00 до 18:00 без опозданий, а более сложное понятие — соблюдение договоренностей, заблаговременное оповещение всех заинтересованных о своем графике присутствия и т. д.

Неизбежно придется изменить подход к контролю и оценке результатов, ведь теперь сотрудник то работает из дома, то присутствует в офисе в то время, когда нет руководителя, одним словом — его не особо видно, а работа должна делаться.

По какой бы причине вы ни решили начать использовать гибкие формы организации труда, помните одно: это изменит вашу компанию, изменит саму работу, изменит сотрудников. Каждый должен будет стать чуть более ответственным, чуть более внимательным ко времени других, чуть более свободным и счастливым.

Репликация: База Знаний «Заказных Информ Систем» → «Как помочь сотрудникам жить счастливой и здоровой жизнью?»

Должно ли описание вакансии нести информацию о компании?

2014-09-03T09:30:15Z

AlenaKolyaseva:

На портале «Планета HR» опубликован комментарий Анны Рид, HR-партнера направления «Финансовые институты», о построении текста вакансии. Почему так важна формулировка открытой вакансии? Каковы этапы ее создания? Чем вакансия отличается от позиции, а внутренняя формулировка — от внешней? Об этом — в комментарии к материалу «Должно ли описание вакансии нести информацию о компании?».

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

Понимая, что первое впечатление кандидата очень важно, мы уделяем много внимания описанию вакансий. Конечно, мы еще находимся в начале пути к «идеальной формулировке», но уже можно говорить о некоторых положительных тенденциях.

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

Позиция в нашем понимании — это набор деятельностей в конкретном подразделении, объединенных в специализацию (например, тестирование, аналитика, разработка, управление и т. д.). А вакансия — это уже требования к конкретному кандидату (профессиональные, личностные, соответствия корпоративной культуре).

Путь от появления потребности в новом сотруднике и определения его позиции до формулировки вакансии состоит из нескольких этапов.

На первом этапе основными «действующими лицами» выступают HR-партнер и руководитель структурного подразделения, являющийся заказчиком подбора.

Основная задача — определить потребность в дополнительном ресурсе, загрузку и структуру деятельности на новой позиции, а также распределение работ внутри подразделения по аналогичным позициям.

HR-партнер и руководитель должны ответить на следующие вопросы:

Почему выделяется позиция?

Под какой объем деятельности?

Какова предполагаемая структура работ по видам деятельности и как она распределена по временной шкале?

Какой квалификационный уровень требуется, каков уровень сложности деятельности?

Какие базовые и специфические компетенции требуются на этой позиции?

По каким критериям сотрудник будет оцениваться на испытательном сроке?

В какой срок нужно закрыть позицию?

В процессе обсуждения может оказаться, что открывать вакансию необязательно и вопрос можно решить иначе, например:

перераспределением загрузки среди имеющихся сотрудников отдела;

перестроением процессов группы для повышения эффективности работы;

ротацией персонала (из смежного отдела или другого направления).

Если же деятельности набирается на 100%-ную загрузку нового человека и принимается решение об открытии вакансии, мы переходим к описанию вакансии для внутреннего использования.

На этом этапе HR-партнер уступает место менеджеру по подбору. В его зону ответственности входит составление сначала внутренней, а затем внешней формулировки вакансии. Менеджер по подбору общается напрямую с руководителем, выясняя требования и постепенно формируя картинку «идеального» кандидата.

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

По факту, от структуры деятельности мы переходим к требованиям к конкретному кандидату.

На этом этапе мы дополняем описание позиции специфическими для компании и проекта особенностями, такими как:

требуемый опыт (на каких должностях, в каких компаниях);

карта мотивации кандидата;

возможности и перспективы для кандидата;

уровень компенсации;

личностные качества и т. д.

Третий этап — составление описания вакансии для размещения на внешних ресурсах. Теперь менеджер по подбору, имея описание позиции и целостное представление о деятельности и человеке, который нам нужен, может сформулировать вакансию для публикации. Наша цель — сделать описание понятным, интересным и читаемым, чтобы кандидат мог «примерить» предлагаемую позицию на себя. Мы стараемся включить в текст вакансии информацию о компании, специфике нашей деятельности и ожиданиях от будущих сотрудников и при этом не перегрузить его.

Таким образом, комплексный подход к открытию и описанию вакансий помог нам:

создать общее информационное пространство руководителя, HR-партнера, менеджера по подбору и избежать ошибок недопонимания;

сделать описания вакансий более понятными и привлекательными;

повысить вовлеченность менеджера по подбору;

уменьшить риск несовпадения ожиданий компании и нового сотрудника;

повысить эффективность и качество подбора.

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

Репликация: База Знаний «Заказных Информ Систем» → «Должно ли описание вакансии нести информацию о компании?»

Коммунальный коммунизм (о причинах кризиса в ЖКХ)

2014-09-02T09:43:59Z

AlenaKolyaseva:

В журнале «БОСС» опубликован комментарий Максима Михалева, нашего директора по развитию бизнеса, о причинах кризисных явлений в ЖКХ. Почему накапливаются задолженности со стороны населения, повышаются тарифы на услуги, а инфраструктура не улучшается? Об этом — в комментарии к материалу «Коммунальный коммунизм» на сайте и в бумажной версии журнала.

Наблюдаемые последние несколько лет кризисные явления в сфере ЖКХ носят системный характер. Во многом они обусловлены текущим форматом взаимодействия между ключевыми участниками этого рынка — управляющими компаниями, ресурсоснабжающими организациями, органами власти и населением.

В этой системе взаимоотношений управляющие компании оказались естественным слабым звеном. Действительно, согласно текущему законодательству управляющие компании являются посредниками между населением и поставщиками ресурсов в вопросах расчетов, начислений и сбора денег за услуги и потребленные ресурсы. В результате сложилась ситуация, когда небольшая компания с минимальным уставным капиталом и, зачастую, без каких-либо существенных активов, получает возможность распоряжаться денежными средствами, в которых её собственная доля составляет всего 5–20% от общего объема. Таким образом, для управляющих компаний создан соблазн использовать проходящие через них деньги в собственных интересах, начиная от банальных задержек платежей, предназначенных поставщикам, заканчивая прямыми хищениями с последующим банкротством самих управляющих компаний.

Неизбежным следствием такой организации рынка ЖКУ является появление букета проблем, которые обычно и упоминаются, когда говорят о кризисе. Во-первых, неплатежи и задолженности за услуги ЖКХ со стороны населения. В текущей системе управляющие компании никак не заинтересованы в повышении сборов денежных средств с населения — свою часть они всегда могут получить из общей массы собранных денег, фактически перекладывая недобор на поставщиков.

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

В-третьих, в сложившейся ситуации никто, кроме населения и местных властей, не заинтересован в модернизации изношенной инфраструктуры и в повышении качества услуг ЖКХ. Пока растущие издержки можно компенсировать ростом тарифов, не приходится ждать массовых инвестиций в инфраструктуру.

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

Репликация: База Знаний «Заказных Информ Систем» → «Коммунальный коммунизм (о причинах кризиса в ЖКХ)»

Сквозное управление ИТ в банке: от бизнеса до «железа»

2014-06-04T12:33:25Z

AlexandraVelyaninova:

В «Национальном банковском журнале» (№5/2014) опубликовано интервью с Сергеем Тихомировым, первым заместителем генерального директора нашей компании, и Александром Габидулиным, заместителем генерального директора по ИТ-инфраструктуре, посвященное сквозному управлению ИТ в банке. Почему происходит рассогласование ИТ- и бизнес-векторов в финансово-кредитных организациях? Что понимается под сквозным управлением ИТ и какие преимущества оно может дать бизнесу? Почему ИТ-инфраструктурное подразделение стоит рассматривать как полноценного бизнес-партнера? Об этом — в интервью «Сквозное управление ИТ в банке: от бизнеса до «железа» на сайте и в бумажной версии журнала.

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

NBJ: Что изменилось за последние годы, что мы говорим о необходимости изменения подхода к управлению ИТ в банках? Почему текущие схемы работы становятся менее эффективными?

С. Тихомиров: Скорость развития современных банков значительно, просто в разы превышает ту, что была 10–15 лет назад. Задачи становятся все более сложными: если раньше российские банки находились в «догоняющей» позиции и преимущественно использовали западный опыт и примеры из смежных областей, которые удавалось адаптировать под собственную ситуацию, то сейчас конкуренция растет и банки все чаще разрабатывают совершенно новые продукты и технологии, которые не имеют рыночных аналогов. В такой ситуации ИТ может стать существенным конкурентным преимуществом и инструментом повышения эффективности работы банка. Но только если весь ИТ-контур банка от бизнес-аналитики до ИТ-инфраструктуры будет мыслиться и управляться как целостная структура.

NBJ: А что мы имеем сейчас?

А. Габидулин: Сейчас в большинстве крупных и средних банков есть несколько обособленных ИТ-подразделений, они могут быть «нарезаны» и называться по-разному — например, подразделения развития, эксплуатации и ИТ-инфраструктуры, — но суть от этого не меняется. Несмотря на видимую эффективность выстроенного между ними взаимодействия, каждое из них решает свои задачи и слабо представляет цели и возможности других.

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

Конечно, у такой обособленности ИТ-подразделений есть фундаментальные причины. Они просто встроены в разные рынки — рынок ПО и рынок оборудования — со своими слабо согласованными целями и циклами развития, разными языками общения и традициями подготовки специалистов.

NBJ: Но может, некоторая обособленность естественна? В конце концов, предметы и объекты деятельности у них действительно разные.

С. Тихомиров: Проблема в том, что при таком подходе ни бизнес, ни даже подразделение, отвечающее за развитие ИТ-сервисов, не видит в ИТ-инфраструктуре инструмент развития, а проектированием изменений в ИТ-инфраструктуре занимаются люди, имеющие «бытовые» представления о ее возможностях.

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

Подразделение ИТ-инфраструктуры, которое последним узнает о планах бизнеса, становится или «перекачанным» возможностями так, чтобы в него «уместилось» любое требование бизнеса, или в один прекрасный момент оно окажется просто не готовым к необходимым изменениям. Выводы об эффективности ИТ-инфраструктуры при обоих раскладах очевидны.

А. Габидулин: Потеря эффективности — это еще полбеды, ведь банк упускает возможности, которые могут дать актуальные тренды в области ИТ-инфраструктуры, а значит, теряет потенциальные конкурентные преимущества.

NBJ: Например?

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

С. Тихомиров: Распространенный пример рассогласованности ИТ-векторов и упущенных инфраструктурных возможностей — излишняя унификация инфраструктурных подходов без учета бизнес-смысла. К примеру, в инфраструктурной политике банка прописывается, что в качестве СУБД используется широко распространенная технология от лидера рынка баз данных. Но в случае конкретного бизнес-запроса более удачным решением могла бы стать другая технология, которая дала бы значительный выигрыш в эффективности или предоставила возможности, не предусмотренные тем самым лидером в его продукте. Однако политика в данном случае буквально «ограждает» инфраструктурное подразделение от погружения в бизнес-смыслы, еще больше увеличивая его изоляцию.

NBJ: И как, на ваш взгляд, можно «переломить» эту ситуацию? Как согласовать разнонаправленные векторы? На первый взгляд, задачка не из простых.

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

Конечно, чтобы такие изменения состоялись, бизнес должен быть в них заинтересован. Росту интереса бизнеса к инфраструктурному слою и запуску процессов совместного проектирования способствует появление рыночных технологий, например, по работе с Big Data, в которых «прикладной» и инфраструктурный уровни неотделимы или инфраструктурная составляющая является «ведущей». Сюда можно отнести и периферию удаленного банковского обслуживания — банкоматы, платежные и POS-терминалы, — которая, по сути, является прямым «исполнителем» бизнес-задач и определяет способ предоставления услуг клиентам.

А. Габидулин: В целом рыночные тенденции таковы, что ИТ-инфраструктура, во всяком случае, в тех местах, где она может стать инструментом развития, начинает все больше восприниматься как полноправный партнер бизнеса, а не как «обеспечивающее» подразделение. Это может стать первым шагом к выстраиванию сквозного управления от бизнес-задач, которое, я уверен, способно дать многократный рост эффективности ИТ в банке.

NBJ: Спасибо за беседу.

Репликация: База Знаний «Заказных Информ Систем» → «Сквозное управление ИТ в банке: от бизнеса до «железа»»

DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)

2014-05-25T21:26:24Z

MaksTsepkov:

----

Репликация: База Знаний «Заказных Информ Систем» → «DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)»

Этот доклад был рассказан на конференции AnalystDays – 2014. Он сделан на основе одноименного доклада на HappyDev – 2013, при этом дополнительно рассмотрены варианты разделения ответственности между аналитиком и разработчиком в разных проектах и позиционирование проектирования по моделям в этих вариантах, а также тема разделения контекстов в DDD.

Доклад на сайте конференции
Презентация на Slideshare
Видео на vimeo

DDD - модель вместо требований (Максим Цепков на HappyDev-2013)

2014-02-16T15:03:07Z

MaksTsepkov:

----

Репликация: База Знаний «Заказных Информ Систем» → «DDD - модель вместо требований (Максим Цепков на HappyDev-2013)»

Доклад на сайте конференции

Сталкивались с тем, что требования сложно формализовать и поддерживать актуальность?

Есть много подходов - user story, use case и т.д., но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

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

Роли в проекте: как поделить поляну ответственности (Максим Цепков на HappyDev-2013)

2014-02-16T15:02:43Z

MaksTsepkov:

----

Репликация: База Знаний «Заказных Информ Систем» → «Роли в проекте: как поделить поляну ответственности (Максим Цепков на HappyDev-2013)»

Доклад на сайте конференции

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

Основные активности - управление, аналитика, разработка, тестирование - никуда не уходят, но можно по разному делить между людьми ответственность за них.

В докладе я покажу разные варианты распределения ролей и ответственности в команде в зависимости от исходных условий и личностных особенностей участников проекта.

Миссия как инструмент против трений

2014-01-14T16:48:49Z

AlexandraVelyaninova:

Владимир Рахтеенко, наш генеральный директор, ответил на вопросы журнала Chief Time о миссии компании. Насколько важно понимать предназначение организации? Что это дает руководителю? Как сформулировать миссию своего бизнеса? Комментарии Владимира опубликованы в статье «Миссия как инструмент против трений» в мартовском номере издания.

Chief Time: Нужно ли руководителю осознавать предназначение своей компании?

Владимир Рахтеенко: Когда-то великий Леонардо да Винчи в работе «О заблуждении тех, кто пользуется практикой без науки» писал: «Те, кто влюбляется в практику без науки, подобны кормчим, выходящим в плавание без руля и компаса… Практика всегда должна быть построена на хорошей теории».

Следуя за его мыслью, могу сказать, что руководитель без миссии — это капитан корабля без руля и компаса. Бизнес без миссии — это просто «тупое» зарабатывание денег.

Мне лично близко определение миссии по Акоффу. По его мнению, миссия — это очень общая цель, вызывающая у каждого члена организации и у всех них чувство устремленности к чему-то. Миссия может мобилизовать компанию на конкретные действия. Это планирование образа чего-то очень желательного и в то же время обязательного.

CT: Что дает понимание предназначения владельцу компании, что — сотрудникам и что — клиентам?

В. Р.: Можно сказать, что для владельца и ведущих сотрудников миссия — это объединяющая цель, или компас, помогающий следовать выбранному направлению развития компании.

Для владельца миссия — это инструмент проведения стратегических изменений в организации, способ трансляции его идей ключевым сотрудникам, позволяющий задать направление движения и пути достижения целей.

Для ключевого персонала — это ориентиры развития на несколько лет. Миссия помогает сотруднику осознать, соответствуют ли стратегические цели компании его личным ценностям и устремлениям, хочет ли он работать именно в этой организации, готов ли он двигаться в тренде ее изменений.

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

CT: Как сформулировать для себя миссию своего бизнеса?

В. Р.: Чтобы сформулировать миссию бизнеса, нужно «всего лишь» объяснить себе, как и почему ваша предпринимательская идея будет жить через 15–20–25 лет. Это как ответить, в чем для вас как для предпринимателя смысл жизни. По Шумпетеру, предприниматель — это всегда новатор. Предпринимательство требует творческого подхода и неотделимо от личности самого предпринимателя. Так что сформулировать для себя миссию — значит рассказать, что нового вы предлагаете миру и как оно будет воплощаться не только здесь и сейчас, но и на горизонте двух-трех десятков лет.

CT: Формулировка миссии для покупателей, для сотрудников и для собственников — должны ли они отличаться друг от друга?

В. Р.: Содержание миссии, естественно, не зависит от адресата. Отличаются только способы ее трансляции для разных аудиторий: для каждой из заинтересованных групп акцент делается на том, что для нее особенно значимо. Клиентам важно то, на что они могут рассчитывать при долгосрочном партнерстве с компанией. Сотрудникам нужно понимать, в какой системе ценностей они будут работать. Собственнику важно сформулировать для себя значимость тех новаций, которые он готов нести в мир.

Репликация: База Знаний «Заказных Информ Систем» → «Миссия как инструмент против трений»

ИТ-инфраструктура современных компаний: общие тенденции

2013-12-25T13:03:22Z

VladMarkov: переименовал ИТ-инфраструктура современных компаний:общие тенденции в ИТ-инфраструктура современных компаний: общие тенденции: Заг…

В журнале Intelligent Enterprise (№4/2013) опубликована статья нашего ведущего системного инженера Дмитрия Морозова, посвященная современным общим тенденциям в развитии бизнеса, которые по-новому влияют на развитие ИТ-инфраструктуры. Какие требования предъявляются к ИТ-инфраструктуре со стороны бизнеса? Как меняются эти требования в связи с бурным развитием мобильных и сетевых технологий? Почему специфика бизнеса на современном этапе уходит на второй план по отношению к ИТ-инфраструктуре? Об этом — в статье «ИТ-инфраструктура современных компаний: общие тенденции» на сайте и в бумажной версии журнала.

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

Важной особенностью современных больших компаний является оперативность, точность и работа с огромным количеством информации, которую необходимо хранить и защищать. ИТ-инфраструктура таких организаций, состоящая из большого числа компонентов — приложений, коммуникационных сервисов, инфраструктуры серверов, АРМ и систем хранения данных, системы информационной безопасности, сетевой и инженерной инфраструктуры, — требует системного подхода к управлению. Ключевыми задачами являются грамотный выбор программных и аппаратных решений, адекватное управление всеми системами организации, обеспечение бесперебойности и безопасности работы.

Традиционно требования различных компаний к ИТ-инфраструктуре зависят от особенностей бизнеса.

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

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

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

Переход к персональной работе с каждым клиентом требует хранения, обработки и защиты огромных объемов информации. Если для банков работа с персональными данными клиентов всегда была одним из ключевых процессов, то для торговых сетей это — новый тренд. Массовый выпуск скидочных и бонусных карт, запуск разнообразных промоакций и других программ лояльности позволяет торговым компаниям собирать и анализировать персональные данные покупателей, которые нужно также хранить и защищать.

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

Стремительное развитие мобильных и интернет-технологий заставляет компании очень быстро принимать решения и реагировать на изменения. Интернет- и мобильные продажи, RFID-метки, бесконтактные технологии платежей, Self Checkout кассы самообслуживания — в борьбе за современного «продвинутого» покупателя компании постоянно придумывают новые технологичные способы продаж. Аналогичные процессы можно наблюдать и в банковской сфере: если раньше вывод на рынок нового банковского продукта занимал несколько недель, то с развитием новых технологий это время сокращается до нескольких часов.

Эти тенденции делают особенно значимыми следующие требования к ИТ-инфраструктуре (см. рисунок):

бесперебойная работа;

масштабируемость;

безопасность;

скорость изменений;

прозрачность и управляемость;

адекватная стоимость владения.

Требования современных крупных компаний к ИТ

Рассмотрим, как перечисленные требования отражаются в необходимых свойствах ИТ современных крупных компаний.

Управление справочными данными:гибкий подход

2013-12-23T17:14:50Z

KseniyaKirillova:

Михаил Заборов, руководитель стратегических проектов, рассказал журналу Intelligent Enterprise о подходах и практиках управления справочными данными в компаниях, также об ограничениях применения MDM-систем. Почему универсальная MDM-система является всего лишь одним из способов организации работы со справочными данными? Что необходимо для эффективного управления нормативно-справочной информацией организации? Об этом — в статье Управление справочными данными: гибкий подход на сайте и в бумажной версии журнала.

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

Однако подобный унифицированный подход нередко приводит к таким сложностям при вводе и обработке справочной информации, из-за которых и сам бизнес теряет эффективность. Мы постараемся показать, что универсальная MDM-система — это всего лишь один из способов организации работы со справочными данными, а для эффективного управления нормативно-справочной информацией необходимо тщательное проектирование информационного обмена между IT-системами, который в каждой компании имеет свои особенности.

Корпоративный ЦОД: за и против

2013-12-23T15:50:14Z

AlexandraVelyaninova:

В журнале «Технологии и средства связи» (№4/2013) опубликована статья ведущего системного инженера Дмитрия Морозова, посвященная вопросам эффективной эксплуатации корпоративных ЦОД, плюсам и минусам размещения IT-инфраструктуры в коммерческих и корпоративных ЦОД, а также особенностям управления IT-инфраструктурой в привязке к бизнес-процессам организации. Об этом — в статье «Корпоративный ЦОД: за и против» на сайте и в бумажной версии журнала.

Клиентоориентированность — главное условие успешной работы на ИТ-рынке

2013-12-23T14:10:50Z

OlgaChekhunova:

На сайте издания CRN опубликована статья директора по развитию бизнеса Максима Михалева, посвященная основным тенденциям российского ИТ-рынка и клиентоориентированности как главному секрету успешной работы в этой сфере. Почему падает спрос на «коробочное» ПО и как выходят из ситуации игроки, работающие в данном сегменте? Что такое клиентоориентированная автоматизация и как выстроить долгосрочные партнерские отношения с заказчиком? Что необходимо компаниям, чтобы успешно выживать и развиваться на рынке заказной разработки в нише крупных информационных систем? Эти вопросы чрезвычайно остро стоят перед поставщиками и заказчиками крупных ИТ-решений, и наш эксперт делится секретами успеха и видением ситуации.

DDD для корпоративных систем - модель вместо требований (Максим Цепков на ЛАФ-2011)

2013-11-19T21:18:24Z

MaksTsepkov:

Доклад на ЛАФ-2011

Видео с конференции http://blogs.uml2.ru/post/Maksim-Cepkov-Domain-Driven-Design-model-vmesto-trebovaniy

В докладе рассказывается про Domain Driven Design, который является эффективным и развивающимся подходом к проектированию. DDD говорит о построении модели, которая рождаясь как модель предметной области, развивается в модель системы. Модель заменяет традиционные требования, которые в этом процессе служат лишь для построения и изменения модели, после чего теряют актуальность. Модель строится на Едином языке, которой является основой общения всех участников процесса — от стейкхолдеров и пользователей заказчика до разработчиков и службы поддержки, включая, естественно, и аналитиков, которые вырабатывают этот язык совместно с остальными.

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

Видео с конференции http://blogs.uml2.ru/post/Maksim-Cepkov-Domain-Driven-Design-model-vmesto-trebovaniy

Презентация

Репликация: База Знаний «Заказных Информ Систем» → «DDD для корпоративных систем - модель вместо требований (Максим Цепков на ЛАФ-2011)»

Highload-2013: Отчёт Виталия Филиппова

2013-11-11T22:04:47Z

VitaliyFilippov: /* Как рассуждать о производительности хранилищ баз данных / Mark Callaghan (Facebook) */

Информация о конференции, организация:

Highload-2013, «Конференция разработчиков высоконагруженных систем». Проходила в очередной раз в конференц-зале гостиницы Radisson на м. Киевская.
Самая первая и самая распиаренная из Бунинских конференция. Билет стоил аж 21000, плюс ещё были отдельные «учебный» и «VIP» дни (на которых я, естественно, не был).
Хайлоад начался с хайлоад-очереди на регистрацию. В разные обработчики она, правда, почему-то была разная (очередь с приоритетами, где каждый оценивает свой приоритет сам?), и встав в другую, ты терял времени на порядок-два меньше.
Вайфай нормально не работал, до отваливания в нём удавалось посидеть минут 5.
С едой всё было более-менее в порядке — кофе-чай всё время, 2 перерыва, каждый из которых для части людей — кофе-брейк с плюшками, а для другой части — обед (балансировали нагрузку талонами). Небольшие трудности с обедом — народу много, места сесть не хватало, часть еды быстро кончалась. Но голодным там всё равно никто не оставался.
Дали большую кучу раздаточных материалов — книжку с частью докладов с прошлой конференции, диск, рекламу, 3 блокнота… Полезный элемент — в этом году вместо ахтунг-стайл красной авоськи дали сумку для ноутбука, в которую и был упакован весь выданный crap.

Общая атмосфера:

Атмосфера в целом какая-то «коммерческая», видно, что компании туда ходят уже по накатанной для регулярного пиара.
Докладчики (компании) — всё одни и те же лица, посетители — наоборот, похоже, исключительно новые. Правильно Стас выразился — это как с борделем, нормальный человек ходит туда 1 раз в жизни; это ты ходишь постоянно, и тебя уже ничем не удивишь.
Девушек на конференции не было почти совсем, «радостную» программистскую тусовку разбавить было некем.
Многие зарубежные «звёзды», как обычно, лили воду, содержательной части в докладах от FB, например, процентов 10.
Было много докладов от одних и тех же компаний — может это и не плохо, но по-моему свидетельствует о неком спаде доступного разнообразия (или слабом подборе). Ну и badoo (которое сайт знакомств и вообще непонятно, почему в 21 веке имеет столько юзеров) уже слушать как-то неинтересно. Примеры повторов:
По 3 доклада от Badoo и 2ГИС; по 2 от Одноклассников, Facebook, Monty Program AB, Qrator/HLL, mail.ru, HashiCorp. К этим в общем-то претензий нет, понятно, что вторых таких же чуваков, как Qrator, найти сложно.

Блог Максима Цепкова - оглавление

2013-11-11T18:50:33Z

MaksTsepkov:

Первоначально я вел блог на uml2.ru и продолжаю постить туда ссылки на новые статьи
Потом больше года публиковался на SoftwarePeople Доступ утрачен с закрытием портала
Потом был здесь, на сайте компании Блог:Максима Цепкова
А с 19.05.2014 переехал на личный сайт http://mtsepkov.org/Blog и туда скопированы посты с данного сайта, восстановлены посты с SoftwarePeople и будут скопированы с uml2.ru

В этой статье собраны оглавления всех моих блогов до пенезда на личный сайт.

Блог:Максима Цепкова

Мои посты на SoftwarePeople (и немного на uml2)

2013-06-11 По следам MS DevCon-2013
2013-05-28 AnalystDays-2013
2013-04-30 SQAdays-13 (весна 2013)
2013-04-15 SoftwarePeople-2013
2013-04-11 Мастер-классы Эдварда Йордана перед SoftwarePeople-2013
2013-03-31 AgileDays 2013 - между скрамом и будущим
2013-03-29 Как появляется PBL - Jeff Patton на AgileDays
2013-03-22 Клуб директоров по разработке встреча 21.03
2013-03-16 Enterprise Developers Conference
2013-03-10 OMG Essence
2013-02-22: MODELSWARD - подвожу итоги
2013-02-20 MODELSWARD - первые впечатления
2012-12-20 Проектирование программ: мастера и самоучки
2012-12-02 SQAdays-12, день второй
2012-12-01 SQAdays-12, день первый
2012-11-29 KM Russia-2012, день второй
2012-11-28 KM Russia-2012, день первый
2012-11-19 SPMconf-2012 Минск - день второй
2012-11-17 SPMconf-2012 в Минске - день первый
2012-11-13 ReqLabs-2012 в Киеве
2012-11-03 SECR-2012, день второй
2012-11-02 SECR-2012 - день первый
2012-10-31 SECR-2012, курс Билла Кертиса
2012-10-25 Гики и Менеджеры
2012-10-25 Пока мы наступаем, Microsoft меняет рельеф местности
2012-08-07 Запад и Япония: два взгляда на бизнес-процессы
2012-05-01 Agile как IT-форма современного менеджмента

Блог на uml2.ru

2012-06-25 ЛАФ-2012
2012-06-11 AgileKitchen 11.06.2012
2012-06-01 Заседание Клуба директоров по разработке об архитектуре
2012-05-28 AnalystDays-1
2012-05-13 ADD-2012 - передний край разработки
2012-04-29 Изменим мир к худшему!
2012-04-29 Три мира программистов
2012-04-24 SQAdays весна 2012 - день второй
2012-04-22 SQAdays весна 2012 - первый день превзошел ожидания
2012-04-18 Желание и Возможность формулируются на разных языках
2012-04-13 SoftwarePeople 2012 - продолжение
2012-04-10 SoftwarePeople 2012 день первый
2012-04-01 Впечатления Atlantic Systems Guild
2012-03-28 Agile как IT-форма современного менеджмента
2012-03-25 Agile Days-2012, день второй
2012-03-24 Agile Days-2012, день первый
2012-01-18 Отчет Управление знаниями - KM Russia 2011
2011-12-25 Культуры IT-компаний
2011-12-12 KMrussia - объясняшки
2011-12-03 10-я конференция SQA Days - день второй
2011-12-02 10-я конференция SQA Days - день первый
2011-11-28 Конференция SPM Conf 2011
2011-11-24 Бизнес-форум управления знаниями - день второй
2011-11-23 Бизнес-форум управления знаниями KMRussia-2011
2011-11-20 Agile и CMMI
2011-11-06 Карта компетенций SFIA
2011-11-03 SECR-2011 завершился
2011-11-03 SECR-2011. Промежуточные итоги
2011-10-31 SECR-2011 день первый - банки
2011-10-26 Снова об Archimate
2011-10-15 Осень - время конференций
2011-06-28 Послесловие к ЛАФ-2011
2011-06-11 Роль аналитика в разработке
2011-05-22 Черный лебедь Талеба
2011-05-13 О разработки фреймворков...
2011-05-06 ADD-2011 - Макс Цепков
2011-05-03 Конференция ADD-2011
2011-04-09 Тренинг Нила Мейдена на SoftwarePeople 2011
2011-04-08 Возвращаясь к REQ-labs
2011-04-08 SoftwarePeople 2011 - день второй
2011-04-07 SoftwarePeople 2011 - день первый
2011-04-04 Впечатления о REQ-Labs 2011 - Макс Цепков
2011-03-13 Тренинг Книберга по Agile - Макс Цепков
2011-03-13 AgileDays-2011 - Макс Цепков
2011-02-23 Getting Things Done
2011-01-27 Конференция и ее результаты
2011-01-21 Требования и стандарты на них
2011-01-13 Стандарты представления знаний
2011-01-07 О стандартах архитектуры
2011-01-05 ArchiMate
2011-01-02 Архитектурные метафоры строительства в IT
2010-12-21 Макс Цепков - отчет о SECR-2010
2010-12-14 О дорогой автоматизации
2010-12-09 Как бороться Аналитику с рутиной
2010-11-29 Мысли - имеют продолжение
2010-11-12 Конференция Управление знаниями - 10.2010
2010-11-01 Рейнвотер. Как пасти котов
2010-10-26 Конференция Управление знаниями
2010-10-25 Осень - время конференций. Управление знаниями.
2010-10-15 SECR-2010 закончился
2010-10-14 SECR-2010 первые впечатления

На этом мой внешний блог заканчивается.

Репликация: База Знаний «Заказных Информ Систем» → «Блог Максима Цепкова - оглавление»

SECR-2013: Отчёт Виталия Филиппова

2013-11-01T13:19:13Z

VitaliyFilippov: /* Осторожно: патентные тролли! Теория, практика и актуальные примеры — Юрий Бардмессер, Bardmesser Law Group */

Конференция «Software Engineering Conference Russia — 2013». Даты проведения — 24-25 октября 2013.
От нас ходило 8 человек, но я, по-моему, так выбирал доклады, что с другими пересекался мало. Хорошо — значит, отчёт будет полезнее :)
Темы — разные, качество докладов — среднее, были интересные, но много и всякой фигни, в том числе долгих «круглых столов».
Докладов много, 4 параллельных сессии в первый день, 5 параллельных сессий во второй.
Место проведения: Digital October. Типичная для него проблема — всё время в проходах ставят мелкие столики, вокруг них толпится народ, и в итоге фиг пройдёшь, всё время расталкивать кого-то приходится.
Торможений в организации не наблюдалось.
Презентации уже есть на сайте — http://2013.secr.ru/, и это тоже хорошо.
Еда: Кофечай был всё время, это хорошо. В перерывах давали довольно гнусные бутерброды, претендующие на вид «мини-бургеров», и печеньки, которые мгновенно сжирались. Обед нормальный, люди как всегда выстраивались в длиннющие очереди, а я применял хак.
Ну какой нафиг software engineering может быть в 9:00? Хоть бы в 10, что ли… :)

DDD: проблемы и решения в отражении модели предметной области в код (Максим Цепков на Software People 2013)

2013-10-21T21:38:19Z

MaksTsepkov: /* Краткое содержание доклада */

Доклад был сделан на конференции SoftwarePeople-2013.

Современные технологии обслуживания клиентов в банках

2013-09-06T13:45:22Z

KatyaNikolaeva:

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

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

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

Современный сервис банка все чаще ассоциируется у клиента с самообслуживанием — общение с операционистом заменяется общением с терминалами, компьютерами и смартфонами. При этом клиент вынужденно сталкивается с большим количеством «технологических изысков»: шифрование данных; ввод постоянных логина и пароля; ввод разовых паролей со скретч-карт для подтверждения операций; ввод смс-паролей, присылаемых на мобильный телефон; использование ключей ЭЦП; виртуальные клавиатуры и др.

Банки комбинируют и интегрируют технологии, скрывая от клиентов сложность процессов обработки информации и выводя мобильные и интернет-платежи на новый уровень безопасности. Например, новинкой на российском рынке стала интеграция возможностей смартфона и pos-терминала. К мобильному устройству клиента подключается небольшой легкий (весом 40 грамм) карт-ридер, оснащенный специальным программным обеспечением. В результате клиент получает защищенный персональный терминал по приему чиповых карт, и в любой момент может сам безопасно оплачивать товары и услуги. Банки выступают эквайринг-партерами и своим клиентам предоставляют льготные условия обслуживания мобильных pos-терминалов. В такие проекты уже вовлечены Альфа-Банк, Промсвязьбанк, Мастер-Банк, Банк Русский Стандарт, Банк Открытие и др.

Репликация: База Знаний «Заказных Информ Систем» → «Современные технологии обслуживания клиентов в банках»

Горячая замена

2013-07-24T16:33:25Z

AlexandraVelyaninova:

Михаил Заборов, наш заместитель генерального директора по стратегическим проектам, рассказал журналу IT Manager о смене управленческого ПО в компании. Почему компании решаются на замену ключевой ИТ-системы? Что лучше — дать ей «долго умирать» или сменить «резким движением»? Как выбрать новую систему и не повторить ошибки прошлого? Об этом — в статье «Горячая замена» на сайте и в бумажной версии журнала. Мы публикуем полный текст беседы с Михаилом.

IT Manager: В каких случаях и по каким причинам, исходя из вашего опыта, компании обычно принимают решение о смене ключевой информационной системы, например, ERP?

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

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

Еще одна распространенная ситуация — когда с ростом компании и развитием бизнеса функционал выбранной вначале системы перестает удовлетворять его требованиям, и устранить эти «разрывы» в рамках существующей системы становится просто невозможно из-за изменения самой концепции бизнеса.

Ну и, наконец, естественная и неизбежная причина замены ИТ-системы — это устаревание технологий, на которых она построена, что в конечном счете упирается в невозможность использования современного Hardware (а старое ни купить, ни поддерживать уже тоже невозможно).

Когда смена системы действительно неизбежна?

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

По каким критериям вы рекомендуете выбирать новую систему?

Главное — четко осознавать, что приобретаемая ИТ-система должна подходить именно вам. Ни бренд компании-поставщика, ни его отраслевой опыт не должны играть здесь такой роли, как то, насколько предлагаемое ИТ-решение способно поддержать бизнес-процессы конкретно вашей компании.

При выборе стоит обращать внимание не только на то, чтобы в системе было «все, что нужно», но и на то, чтобы в ней не было ничего лишнего. Ведь дополнительный функционал удорожает поддержку и существенно усложняет развитие ИТ-системы.

Следующий чрезвычайно важный фактор — это компетентность и мощность команды внедрения. И система, и сама команда должны быть гибкими и способными адекватно реагировать на изменения, а в систему должен быть заложен ресурс развития под нужды клиента, иначе можно столкнуться с ситуацией, когда переделка 5% функционала обойдется в 30% от стоимости всей системы.

Как правильно подобрать команду проекта при смене платформы критически важной информационной системы, чтобы, с одной стороны, обеспечить необходимую преемственность, а с другой — избежать старых ошибок и в результате получить именно то, что необходимо — каковы ваши рекомендации?

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

Крайне желательно, чтобы в таком проекте участвовали специалисты по существующим системам — это не обязательно должны быть представители предыдущего вендора, в их роли могут выступать специалисты заказчика.

Ну и, наконец, важно понимать, что никакая сколь угодно хорошая команда не может гарантировать успех проекта, если нет активности и заинтересованности со стороны заказчика изменений.

Какие трудности характерны для ИТ-проектов, связанных с заменой одной информационной системы на другую?

Ключевая сложность таких проектов — это необходимость обеспечить непрерывное функционирование ИТ-системы заказчика целиком при замене ее части. Это требование может быть критическим для бизнеса, ведь перебои в работе системы зачастую означают остановку ключевых бизнес-процессов и приводят к огромным убыткам.

Кроме того, подрядчик должен учитывать существующий контекст и уметь «бесшовно» встраивать свое решение в имеющийся ИТ-ландшафт. А для этого у команды внедрения должно быть умение и желание разбираться с этим ландшафтом и менять свое ПО в соответствии с ним.

Далее, при внедрении новой системы изменения должны производиться «контролируемыми квантами», чтобы заказчик успевал их «переварить», а подрядчик — внести изменения в процесс внедрения и саму систему, если это необходимо.

Какая схема взаимоотношений между заказчиком и поставщиком информационной системы является наиболее эффективной, на ваш взгляд?

Главное, что необходимо для успеха проекта подобного масштаба, — это партнерские отношения между заказчиком и подрядчиком. Взаимное доверие и уважение, искренняя заинтересованность и работа на общие цели — только в этом случае стороны смогут слаженно и эффективно действовать в условиях сложности и неопределенности. Мы уже много лет работаем с нашими клиентами по неоклассическому контракту: по сути, это означает, что фиксируются только крупные задачи и параметры внедрения, а мелкие детали прорабатываются постепенно, в рабочем порядке. Такая схема позволяет сторонам сконцентрироваться на ключевых моментах и не «спотыкаться» о горы мелочей.

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

Репликация: База Знаний «Заказных Информ Систем» → «Горячая замена»

Управление фирмой, оказывающей профессиональные услуги

2013-07-24T09:27:30Z

AlexandraVelyaninova:

Максим Михалев, наш директор по развитию бизнеса, рассказал порталу Bankir.Ru об одной из наших любимых книг Дэвида Майстера — «Управление фирмой, оказывающей профессиональные услуги». Отзыв Максима опубликован на сайте в рубрике «Люди о книгах».

Интуитивно всем руководителям понятно, что продажа услуг существенно отличается от продажи товаров. Вопрос в том, как избежать типичных ошибок в собственной практике.

Дэвид Майстер — общепризнанный консультант, специализирующийся на вопросах управления фирмами, оказывающими профессиональные услуги. К ним, наряду с аудиторскими, юридическими, рекрутинговыми, инжиниринговыми и инвестиционными компаниями, относятся и такие фирмы, как наша, — оказывающие услуги по проектированию и разработке информационных систем.

Майстер определяет и описывает две основные особенности (они же — потенциальные проблемы) консалтингового бизнеса.

Во-первых, «профессиональные услуги предполагают высокую степень индивидуализации выполняемых работ». К примеру, в нашей компании около 80% задач по сложности относятся к проектам типа «Мозги» или «Седина» (в соответствии с классификацией того же Майстера). На деле это означает, что каждый наш проект — это полностью индивидуальная разработка под конкретные бизнес-задачи клиента, а не типовой продукт, изготовление которого можно поставить на поток.

Во-вторых, «большинство профессиональных услуг имеют сильный компонент личного взаимодействия с клиентом». Значит, качество и сервис приобретают особый смысл и должны особо управляться. Вы не просто продаете товар, вы создаете партнерские отношения с клиентом, которые надо развивать и углублять. Мало выполнить работу качественно с технической стороны, нужно, чтобы клиент получил эмоциональное удовлетворение от сотрудничества.

Книга привлекает конкретикой и опорой на реальный опыт. Распределение людей на проектах, самые эффективные маркетинговые приемы для данной сферы бизнеса, работа с существующими и потенциальными клиентами, повышение уровня качества оказываемых услуг, мотивация, контроль и оценка персонала, стратегии роста и развития компании — Майстер не просто структурированно и доступно рассказывает, почему руководителю нужно всем этим заниматься на постоянной основе, но и дает конкретные советы и рекомендации, как это сделать наилучшим образом. Книга пережила множество переизданий, но по-прежнему актуальна и, как хорошее вино, с годами становится только ценнее.

Репликация: База Знаний «Заказных Информ Систем» → «Управление фирмой, оказывающей профессиональные услуги»

Эффект модерации (Алишер Якупов, WUD-2011)

2013-07-23T12:19:11Z

VitaliyFilippov:

ADD-3: Отчет Моисеева Андрея

2013-07-23T11:57:29Z

VitaliyFilippov:

Был на конференции ADD-3. Очень понравилась организация конференции - как-то очень уютно и по домашнему всё было. Гораздо лучше, чем на SoftwarePeople-2012. А вот качество докладов в среднем было на мой взгляд хуже. Возможно это частично компенсировалось возможностью комфортного общения с авторами заинтересовавших докладов в кулуарах. Далее подробнее о тех докладах, которые я посетил.

ADD 2010: Отчет Мальцевой Екатерины

2013-07-23T11:56:38Z

VitaliyFilippov:

Highload 2009: Отчёт Виталия Филиппова

2013-07-23T11:54:14Z

VitaliyFilippov:

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

McHost пиарился, привёз голых девок. Ещё только сейчас понял, что большинство презентаций были какие-то уж больно фиговые. 5-6 слайдов на полчаса времени?…

Я рассказывал блиц-доклад PHP-разгон: серебряная пуля из автомата Комменца-Вальтера» (Commentz-Walter). Есть корпоративный отчётик с презентацией и видео.

ЛАФ-2013: Отчет Григораш Н. Ю.

2013-07-16T10:45:41Z

VladMarkov:

Кэширование в веб-приложениях - что, где, когда

2013-05-16T14:06:42Z

VitaliyFilippov: /* Замечания */

Slide Show

Автор: Виталий Филиппов
Нижний колонтитул: Кэширование в веб-приложениях - что, где, когда
Дополнительный нижний колонтитул: Виталий Филиппов, 14:42, 21 июня 2013

Тема: Кэширование в веб-приложениях — «что, где, когда»
Формат: лекция
Лектор: Виталий Филиппов
Дата: 16 мая 2013
Время: 1.5-2 часа
Требования к аудитории: Представление о разработке в целом и интерес к веб-разработке в частности :)
Для просмотра презентации в браузере нажмите на картинку справа.
Для просмотра на мобильных и прочих устройствах — PDF-версия: Media:WebAppCache.pdf

Oracle Day 2012:Отчет Белобородова Дмитрия

2013-05-07T07:07:33Z

DmitryBeloborodov:

Оказание юридической помощи в компании

2013-03-19T18:02:37Z

AlexandraVelyaninova:

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

«БОСС»: Как организовано оказание юридической помощи в Вашей компании? Какова модель юридического направления — собственное подразделение, аутсорсинговая структура или и то, и другое?

Екатерина Родыч: С 2007 года наша компания располагает собственной юридической службой, состоящей из двух человек. Ранее (более пяти лет) компания обходилась без профессионального юридического отдела. В настоящее время до 90% юридических задач решается в нашей компании собственными силами. Конечно, некоторые задачи мы отдаем на подряд, если очевидно, что аутсорсеры справятся с ними быстрее и эффективнее. Это, например, вопросы взаимоотношений с государственными органами.

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

Все юридические вопросы на стартапе и в первое время существования бизнеса ввиду незначительности их объема и относительно низкой сложности могут решаться силами бухгалтерии компании. Разработку шаблонов договоров можно заказать у специально обученных аутсорсеров, или же можно «одолжить» шаблоны у контрагентов. Решение каких-то специфических юридических вопросов также можно поручить аутсорсерам.

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

Кстати, интересный, но в целом предсказуемый факт — в течение длительного времени после формирования юридического инхауса юрист компании (обычно сначала он один) имеет довольно сильную загрузку по работе, поскольку «разгребает» результаты юридической деятельности своих предшественников, которые по понятным причинам не обратили в свое время внимания на важные нюансы, а также допустили ряд разнообразных юридических ошибок. Зачастую на этих ошибках бывают построены целые схемы взаимоотношений с третьими лицами. Конечно, первым делом нужно по максимуму все исправлять и строить новые — юридически корректные — схемы деятельности. Это долгий и трудоемкий процесс, а полностью избавиться от следов старых схем в большинстве случаев нереально.

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

«БОСС»: Если есть внутренние юристы, каковы их задачи?

Е. Р.: В нашей компании используется классическая для компаний с не очень значительным объемом юридических задач схема работы юридической службы. Юристы не имеют специализации и занимаются в целом одними и теми же задачами, естественно, разделяя их между собой. Круг задач очень широк и охватывает все сферы деятельности компании: в первую очередь, это налоговые консультации для бухгалтерии, вопросы трудового права, корпоративное право (которое в значительной степень отдано на подряд аутсорсерам), договорная и претензионная работа, а также, естественно, вопросы интеллектуального права, поскольку основной деятельностью нашей компании является разработка программного обеспечения.

В мои обязанности как руководителя службы входит, помимо решения текущих задач, организация взаимодействия внутри отдела, а также с заказчиками наших услуг таким образом, чтобы задачи решались максимально быстро и были верно отранжированы по значимости при их принятии в работу. Кроме того, очень важно, чтобы обеспечивалась целостность решения поставленных задач: заказчик (внешний или внутренний), поставивший задачу юридическому отделу, должен получить на выходе не просто набор норм, абстрактно регулирующих взаимоотношения по данному вопросу без конкретных предложений, а результат «под ключ» — решение конкретно для данного заказчика в указанной им ситуации, с перечислением не только всех плюсов данного решения, но и его подводных камней.

«БОСС»: Как наиболее целесообразно, с Вашей точки зрения, делить работу между внутренними и внешними юристами?

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

Кроме того, решение максимального количества задач собственными силами позволяет юридическому отделу не терять тот самый контекст — в любом случае в задачу, которую выполняешь собственными руками, погружаешься глубже, чем в задачу, отдаваемую на подряд, а иначе зачем ее вообще отдавать?

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

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

«БОСС»: Каковы требования для подбора юристов? Какова должна быть их степень глубины погружения в специфику компании, с одной стороны, и в те или иные направления юридической помощи, с другой?

Е. Р.: Вообще тут все ситуативно. Сильно зависит от размера компании, направлений ее деятельности и других факторов. Если говорить о компаниях вроде нашей — средних размеров, не специализирующихся на юридическом и налоговом консалтинге, работающих в B2B, имеющих надежных контрагентов, не использующих налоговые схемы (то есть с низкими судебными рисками), — то я бы сказала, что для них оптимальным является «универсальный юрист» — человек с широким кругозором и широкой специализацией (пусть и не очень глубокой), обязательно обучаемый, причем оптимально — самообучаемый, поскольку обмен знаниями в маленьких отделах, занимающихся непрофильной деятельностью, невелик, как и в любой маленькой замкнутой системе. Это должен быть человек с гибким мышлением, способный оперативно переключаться между несколькими задачами. Поскольку оформлением документов в компаниях такого типа зачастую занимаются тоже юристы (ввиду отсутствия полноценного договорного отдела), такой специалист должен быть внимательным, аккуратным и не бояться рутинной работы, которой, справедливости ради, хватает в любом виде деятельности.

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

«БОСС»: Где и как Вы находите юристов?

Е. Р.: Сейчас задачи поиска новых сотрудников не стоит. Когда назреет необходимость, вероятнее всего, поиском будут заниматься наши специалисты по подбору по базам резюме. Если не получится найти никого стоящего таким образом, будут привлекаться кадровые агентства.

«БОСС»: Какие типичные ошибки совершают компании при организации юридической помощи?

Е. Р.: Одну из ошибок я уже подробно описала выше — компании часто не уделяют должного внимания юридическому сопровождению своей деятельности до того самого момента, пока не назреет критическая масса юридических проблем. Еще раз повторюсь — это сильно загружает юриста в первое время работы в компании (а это «первое время» может растянуться на значительный срок).

Второй ошибкой со стороны руководства компании является, на мой взгляд, такая оргструктура фирмы, при которой юридический отдел (его руководитель) подчиняется не руководителю компании напрямую. Встречаются случаи, когда юридический отдел подчиняется финансовому управлению. Или наоборот. Почему? Это независимые подразделения, значимые для фирмы. Более того, несмотря на кажущиеся общие цели этих подразделений, во многих вопросах их интересы диаметрально противоположны. И юридический отдел, и другие важные инфраструктурные подразделения компании (бухгалтерия, маркетинг, HR, служба безопасности и т. д.) должны подчиняться непосредственно руководству фирмы и взаимодействовать друг с другом на паритетных основах, чтобы не сбивать друг другу целеполагание (что, конечно, не отрицает необходимости учитывать цели и интересы друг друга и компании в целом).

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

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

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

WikiHelp:Расширенная разметка

2013-01-31T10:56:45Z

AndreyMoiseev:

{{#set: |HelpId=AdvancedMarkup |HelpOrder=1100 |ParentMenuId=Markup |HelpContent=WikiHelpContent:Расширенная разметка |HelpDisplay=Расширенная разметка }}

[Исходная статья]

См. подразделы. {{#ask: ParentMenuId::AdvancedMarkup

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/Aggregate/1

}}

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Загрузка произвольных файлов

2013-01-30T10:21:26Z

AndreyMoiseev:

{{#set: |HelpId=AnyData |HelpOrder=400 |ParentMenuId=Media |HelpContent=Справка:Изображения#Загрузка произвольных файлов |HelpDisplay=Произвольные файлы }}

[Исходная статья]

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

Scrum-checklist

2013-01-25T14:42:00Z

VitaliyFilippov:

Проверочная карта, по которой можно оценить полноту следования процессу Scrum
плюс обнаружить проблемные зоны и почерпнуть дополнительные идеи по улучшению процесса.

[на всё окно][свернуть]

Это вольный перевод на русский язык Scrum checklist, составленного Генрихом Книбергом (автор книги «Scrum and XP from the Trenches»)

Репликация: База Знаний «Заказных Информ Систем» → «Scrum-checklist»