Чтение онлайн

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

Из общей численности персонала SAP (65 тысяч человек по всему миру) примерно 20 тысяч – разработчики программ. Это люди, которые придумывают, пишут, кодируют и оформляют пакеты программных продуктов и услуг корпоративного уровня. И все 20 тысяч человек рассеяны по земному шару. Они трудятся невзирая на границы, различия в культуре и религии. Но руководители SAP понимали: опережать вездесущих конкурентов в условиях нынешнего появления новых прорывных технологий, в частности более дешевого предложения программного обеспечения как услуги, они смогут, лишь сократив время разработки новых продуктов с 14,8 месяца примерно до полугода, причем сделав это в течение ближайших трех лет. Вдумайтесь: сократить время разработки продукта почти на 60 % в компании, которой есть что защищать: 65 тысяч сотрудников (в том числе 20 тысяч программистов), 16 миллиардов долларов дохода, 90 миллиардов долларов рыночной капитализации. Нелегкое решение…

«Размышляя о том, куда должна двигаться SAP, – рассказывал мне Джим Снабе в 2013 году (тогда он был одним из CEO компании), – я не смотрел на наших основных конкурентов – компании такого же масштаба или даже больше. Вместо этого я интересовался маленькими стартапами из Кремниевой долины. Мы посетили некоторые из них, в том числе те, что занимались компьютерными играми, и обнаружили новую гибкую методологию разработки программ, заключавшуюся главным образом в создании прототипов и быстром интегрировании с пользователями».

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

Снабе решился на радикальные шаги. Он собрал своих топ-менеджеров и всех руководителей групп разработчиков, чтобы провести, по его словам, «квест [36] для лидеров». С этой целью они посещали крупные компании из других отраслей, чтобы позаимствовать новые идеи и обрести вдохновение. «Мы побывали в Intel, – рассказывал Снабе. – Мы заехали в Cisco, а еще мы посетили Porsche». Именно последний визит оказался самым полезным, поскольку Porsche удалось в четыре раза увеличить объем производства, подняв прибыльность на 19 %. Как? «Они добились этого, создав множество мини-команд, получивших полномочия постоянно совершенствовать способы управления компанией», – объяснил Снабе.

Впоследствии руководители SAP комбинировали эти две мето– дологии.

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

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

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

Это и есть ключевая идея: маленькие команды получили полномочия принимать собственные решения.

«Неважно, 8, 10 или 12 участников в команде, – говорит Снабе. – Это группа примерно из 10 человек, обладающих компетенцией принимать решения, необходимые для завершения всего цикла проекта, в том числе для обеспечения качества программного продукта, его функциональности и архитектуры. Действуя таким образом, мы, фактически превратившись в кучку стартапов, работаем по единому сводному плану».

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

Результат: SAP сократила время разработки продукта с 14,8 до 7,8 месяца. «За три года мы добились сокращения цикла разработки почти в два раза, – заявил Снабе. – При этом существенно выросло качество продукта. Но перед компанией по-прежнему стоит цель довести время разработки до шести месяцев».

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

История преобразования SAP высвечивает лишь некоторые наиболее важные методики и преимущества, связанные с небольшими высокоэффективными командами.

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

Как вы думаете, какое слово является ключевым в предыдущем предложении? Пытаются. Мы пытаемся. И пытаемся… Но часто терпим неудачу. Бывший программист-предприниматель Вивек Вадхва, ныне присоединившийся к Университету сингулярности, имеет весьма интересный опыт преодоления проблем при создании выдающихся команд и управлении ими. Я нанес визит Вадхве в кампусе университета, расположенном в Кремниевой долине рядом с научно-исследовательским центром Эймса под эгидой NASA. Вадхва сообщил мне, что большая часть проблем с такими группами проистекает от традиционного образования. «Когда вы и я пошли в школу, нас учили быть личностями, – объяснил он. – Мы сидели за партами, ряд за рядом, а учитель у доски передавал нам знания. Мы делали записи в своих тетрадях. Мы возвращались домой и занимались самостоятельно, по собственным учебникам. Затем мы приходили в школу, чтобы пройти тесты. Если мы делились знаниями друг с другом, то преподаватели называли это обманом».

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

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

Понятно, что рынок труда в США и других странах становится все более многообразным по своим характеристикам {28} . Это хорошо. Меняющаяся демографическая ситуация и достижения женщин и меньшинств в области гражданских прав и свобод способствуют созданию организаций, гораздо более разнообразных, или, как говорят ученые, гетерогенных, чем ранее {29} .