Ускорение работы пользователей 1с
Разработки

Первое знакомство с разработчиком

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

На сегодня уровень консалтинга-внедрения снизился? Скорее всего, повысилась функциональность продуктов! Повысилась сложность задач. Расширился их спектр. Появилась потребность в специализации сотрудников-внедренцев. Растут требования клиентов. Повысилась потребность в интеграции специалистов разработчика и персонала клиента при подготовке внедрения и непосредственно при внедрении. 
 
 
 


«Не печалься, что тебя никто не знает, но стремись к тому, чтоб заслужить известность»
Конфуций

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

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

 


Хорошо ли быть большим

 

 

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

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

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

 


Компетенность

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

 


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

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

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

«Опыт — самый лучший учитель, только плата за обучение слишком велика»
Т. Карлейль

 


Сроки и качество внедрений

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

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

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

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

 


Наследование прошлого

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

 


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

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

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

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

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

 


Обратная сторона

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

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

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

 

 

 

Маленький бюджет

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

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

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


 

 
 


Команда и координатор

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

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

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

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


 

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

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

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

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

 


Техническое задание

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


 

 
 


Стоимость проектов

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

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

А какие именно проектные работы можно отнормировать?

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

 


 


Вывод

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

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

Вы работаете с конкретным разработчиком? Он вас устраивает? Сравнивали ли вы с другими разработчиками? Насколько реально быстро ваш разработчик делает то, что вы себе запланировали?
 

 

 
 

Нравится 0 Не нравится
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо зайти на сайт под своим именем.
Добавить комментарий
Ваше имя: *
Ваш e-mail: *
Вопрос: Юзабилити - это удобство работы в программе?
Ответ:
Код: Кликните на изображение чтобы обновить код, если он неразборчив
Введите код: