Текст книги "Франчайзи на грани нервного срыва. Как небольшой фирме-партнеру 1С перестать выживать и начать зарабатывать"

(–) Отрицательный пример, когда сотрудник отказывается от принципа

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

(+) Положительный пример, когда сотрудник руководствуется принципом

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

Готовый документ был опубликован, и с ним был ознакомлен каждый сотрудник. И, конечно, с «Принципами…» знакомятся все новые сотрудники. Но этого все же мало. Имея печальный опыт потери документов в недрах файлового сервера, нужно было сделать так, чтобы «7 принципов поведения в компании» не терялись и все время были под рукой. И тут нам снова помогли плакаты советского периода. В СССР они нас окружали со всех сторон так, как сейчас реклама. Мы напечатали плакаты в типографии и развесили в каждом кабинете офиса. Оказалось, что это очень удобно. В любой дискуссии можно было просто повернуться к плакату и сказать: «Ну, а теперь рассмотрим эту ситуацию с точки зрения принципа номер 6».

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

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

Глава 37. Как быстро рассчитать стоимость проекта[42]42
  Текст этой главы является сокращенным и уточненным изложением статьи Р. Валеева «Сколько стоит автоматизация завода», опубликованной в электронном журнале «Управляем предприятием» (https://upr.ru/article/skol-ko-stoit-avtomatizaciya-zavoda/).


[Закрыть]

Давайте разберемся с причинами, зачем необходимо быстро оценивать стоимость проекта. Таких причин несколько.

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

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

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

Идеальный вариант

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

Представим себе такой разговор. Звонит заказчик и спрашивает:

– Сколько будет стоить автоматизация завода на продуктах 1С?

– Одну минутку. Сейчас открою прайс и посмотрю. Так, «автоматизация аэропорта», «автоматизация банка», «автоматизация забоя» – нет, это не то. А, вот, нашел: «автоматизация завода» – 10 миллионов.

– Долларов?

– Нет, рублей, конечно. Это же отечественное программное обеспечение!

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

Пример строителей

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

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

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

В частности, если строители хотят рассчитать, сколько будет стоить укладка трех балок, то сметчик по соответствующей строке (балки с пролетом 18 м) берет норму «25 часов на укладку каждой балки», умножает этот показатель на количество, например, 3 балки. В итоге получает 75 часов. То есть 1 бригада из 3-х человек за 3 дня уложит эти 3 балки.

Нормы времени в ИТ-отрасли

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

Я лично использовал эти нормы времени для обоснования проекта разработки биллинговой системы. Даже в 2003 году они вызвали достаточно доверия для заключения договора стоимостью свыше 1 миллиона рублей.

Кроме типовых норм времени на программирование задач для ЭВМ от 1987 года, существуют укрупненные нормы времени на разработку программных средств и вычислительной техники от 1986 года. Они отличались между собой. Во-первых, стадиями проекта, для которых предназначались. Во-вторых, типовые нормы оценивали проект в целом – от начала до конца. Укрупненные нормы ориентировались на разработку программ. Нормы на изготовление и сопровождение – на тиражирование программ. В-третьих, в разных нормах использовались разные физические показатели для оценки трудоемкости.

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

Укрупненные нормы времени в нашей компании

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

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

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

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

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

● виды автоматизированных бизнес-процессов;

● типы применяемых программных продуктов;

● объем изменения типового функционала программ;

● объем работ по переносу данных;

● необходимость интеграции с другими программами.

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

Так сколько же нужно времени на проект?

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

– Сколько рабочих мест планируется автоматизировать?

– 30.

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

– «1С: ERP».

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

– Немного.

– Требуется ли переносить данные из других систем?

– Да, только справочники и остатки.

– Требуется ли интегрировать внедряемую программу с другими программами?

– Нет, не нужно.

Получив ответы на свои вопросы, мы буквально через минуту можем сказать: «Стоимость проекта будет от 3 млн 600 тысяч до 8 млн рублей».

Алгоритм расчета прост. Минимальная стоимость проекта – количество АРМ, умноженное на минимальную трудоемкость автоматизации одного рабочего места и на тариф. Получается 3 млн 600 тысяч руб. Далее на основе ответов заказчика вычисляются так называемые «поправочные» коэффициенты, на которые умножают стоимость проекта, полученную в самом начале. Так формируется верхняя граница в 8 млн руб.

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

Приложение 1.

Пример расчета норм времени на проект автоматизации завода

Общие данные проекта:

1) Количество рабочих мест – 30, из них:

ОМТС – 2

Отдел сбыта – 3

Мастер цеха – 3

Кладовщики – 5

ОТ и З – 2

ПЭО – 2

Отдел кадров – 2

Бухгалтерия, общий отдел – 4

Бухгалтерия, расчетчик зарплаты – 2

Автотранспортный цех – 5

2) Внедряется комплекс программ – 1С: УПП (управление, цеха и склады) и 1C: УАТ (автотранспортный цех, бухгалтерия)

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

4) В бухгалтерии внедрена 1С Бухгалтерия 7.7. Требуется перенос остатков.

В расчетной группе, ОТиЗ, внедрен 1С Зик 7.7. Требуется перенос исторических данных за 2 года.

5) Интеграция с другими программами 1С не требуется.

Расчет нормы времени произведем в таблице.

Опишем, как выполняется расчет по таблице, приведенной на рисунке. Во-первых, по названию и содержанию функций рабочего места определяются вид автоматизируемого бизнес-процесса и соответствующий уточняющий коэффициент для каждого АРМ. Во-вторых, уточняется тип программного обеспечения (1С, 1С-Совместно или 1С: Совместимо) и назначается соответствующий коэффициент от 1,0 до 1,4. Таким же образом анализируются объем доработок, требования о переносе денных и требования к интеграции для каждого рабочего места. После чего вычисляется трудоемкость автоматизации по каждой строке как произведение базовой трудоемкости (50 чел. – часов) на количество рабочих мест и на произведение всех коэффициентов. Например, для первой строки таблицы эта формула выглядит так:

50 x 2 x 1,0 x 1,0 x 1,4 x 1,0 x 1,0 = 140 чел. – часов.

Нормы являются тем прочным фундаментом, на котором строится весь ИТ-дом. Они позволяют:

● обосновать расчет стоимости проекта в глазах заказчика (нормы должны быть доступны заказчику);

● учесть значимые факторы, влияющие на цену проекта;

● оперативно выполнить примерный расчет стоимости проекта за короткое время.

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

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

Глава 38. Как долго рассчитывать стоимость доработки

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

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

Отдел продаж:

– Как 40 часов? Да мы сами – бывшие программисты, больше, чем на 16 часов эта доработка не тянет! Клиент побродит по рынку и найдет тех, кто сделает за 8!

Отдел производства:

– 40. Это мы сильно поджались, знали, что вам не понравится. А, вообще, там работы на все 80. Рисков много. Клиенты сейчас пошли капризные, да еще, наверняка, что-то забыли. Нам потом переделывать «за бесплатно».

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

В паспорт вошли следующие разделы и виды работ:

1. Постановка задачи, разработка технического задания (ТЗ).

1.1. Выявление списка заинтересованных сотрудников (пользователей) заказчика:

– для согласования технического задания (ТЗ);

– для согласования технического проекта (решения) (ТП);

– для приемки работ и согласования заказа на доработку (заказ).

1.2. Интервью с каждым пользователем (ТЗ).

1.3. Оформление требований пользователей к доработке в виде технического задания.

1.4. Презентация технического задания на общем совещании пользователей ТЗ (при возможности) или отдельно каждому, разъяснение содержания, ответы на вопросы.

1.5. Доработка и согласование технического задания с каждым заинтересованным пользователем (ТЗ).

1.6. Предварительная оценка трудоемкости (подготовка предварительного паспорта доработки).

2. Разработка технического проекта (технического решения) (ТП).

2.1. Проектирование информационной модели доработки (какие объекты и реквизиты будут созданы заново, изменены, удалены).

2.2. Проектирование функциональной модели доработки (какие функции будут разработаны, изменены, удалены).

2.3. Описание алгоритмов для новых и изменяемых функций.

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

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

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

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

2.8. Доработка и согласование технического проекта с уполномоченными специалистами заказчика (ТП).

2.9. Окончательная оценка трудоемкости (подготовка окончательного паспорта доработки).

3. Доработка программного обеспечения.

3.1. Технические работы – создание (копированием) отдельной информационной базы данных (при необходимости), получение доступа в хранилище и прочие подготовительные работы.

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

3.3. Разработка новых и изменяемых форм меню, экранных форм объектов метаданных, удаление ненужных форм.

3.4. Разработка кода для общих модулей конфигурации, модулей объектов метаданных.

3.5. Разработка новых и изменяемых печатных форм, удаление ненужных печатных форм.

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

3.7. Разработка подсказок (help-ов) для новых и изменяемых объектов метаданных.

3.8. Разработка и (или) настройка ролей и прав доступа.

4. Подготовка тестового примера.

4.1. Подготовка описания тестового примера (какие исходные данные будут введены в программу, какие данные в результате будут получены, описание порядка действий пользователя для получения результатов).

4.2. Ручное (в Excel) вычисление необходимого эталонного результата на основе исходных данных.

5. Тестирование доработки.

5.1. Ввод исходных данных тестового примера в программу.

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

5.3. Отладка программы в объеме, необходимом для получения эталонных результатов.

6. Разработка инструкции по использованию доработки.

6.1. Разработка краткой технологической инструкции (описание последовательности действий пользователя).

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

7. Первичная сдача доработки пользователям.

7.1. Демонстрация доработки пользователям (заказ), ответы на вопросы, фиксация замечаний.

. Доработка по результатам первичной сдачи.

8.1. Доработка и согласование технического задания (при необходимости).

8.2. Доработка и согласование технического проекта (при необходимости).

8.3. Доработка и согласование паспорта доработки (если трудоемкость изменилась более, чем на 10 %).

8.4. Доработка конфигурации.

8.5. Доработка тестового примера (при необходимости).

8.6. Доработка инструкции (при необходимости).

9. Окончательная сдача доработки пользователям.

9.1. Демонстрация доработки пользователям, демонстрация устранения замечаний по списку замечаний.

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

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

10. Помещение доработки в тиражируемое решение (при необходимости).

10.1. Работы по помещению доработки в тиражируемое типовое решение – постановка задачи архитектором типового решения по необходимой модификации доработки под требования типового решения (работа архитектора).

10.2. Модификация доработки под архитектурные требования (без потери потребительских свойств):

– Тестирование типового решения с помощью комплексных автотестов для исключения сбоев в очередном релизе;

– Первичная сдача работы архитектору типового решения;

– Помещение доработки в хранилище типового решения;

– Повторная сдача доработки архитектору после помещения в хранилище (обязательно) (работа программиста).

10.3. Первичная и вторичная приемка доработки архитектором типового решения (работа архитектора).

11. Подписание заказа.

11.1. Подписание заказа, подтверждение приемки работ с уполномоченными сотрудниками (заказ).

Как общаться с заказчиком, используя такой паспорт?

Тут есть три варианта.

1. Отправить полный паспорт, если заказчик имеет свою службу ИТ и требует детальной сметы.

2. Отправить укрупненный паспорт, в котором 11 строк с трудоемкостью разделов, но нет расшифровки отдельных разделов. Давать такую расшифровку – только если заказчик потребует. Такой паспорт может упростить понимание состава работ неподготовленному заказчику.

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