Все плюсы и минусы «переделки под себя» типового ПО

Все плюсы и минусы «переделки под себя» типового ПО

Сергей Соловьев Менеджер интернет-проекта, Москва

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

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

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

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

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

Какие конкретно конкретно преимущества дают адаптации? В чем их не сильный стороны? На что направляться обращать внимание? Чего беспокоиться? Ехecutive.ru задал эти вопросы специалистам по информационным разработкам.

Своим опытом поделились: управляющий компании «Реалтис» Антон Колганов – начальник с опытом управления IT в больших бизнес-организациях (на фото справа); председатель совета директоров компании «Миракл коммюникейшн» Сергей Милохов – эксперт с двадцатилетним опытом автоматизации на платформе 1С.

1.Чем отличаются адаптированные ответы?

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

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

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

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

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

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

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

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

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

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

2. Что возможно и чего нельзя адаптировать?

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

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

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

  • Внутренняя структура уже имеющегося ПО спроектирована под другие бизнес-процессы. Другими словами дорабатывать практически нечего, через чур большой объем работ по переделке.
  • Нечитабельность, запутанность исходного кода программы, его низкий уровень качества, непонятная логика, нехорошая документация, или ее отсутствие.
  • Разработчик IT-продукта изначально желал исключить вмешательство в код сторонних экспертов и предусмотрел защиту. Это смогут быть как юридические, так и технические препятствия, а обычно дружно.

3. В то время, когда выгодно приспособить ПО?

С. М.: Выгодно, в то время, когда бизнес-процессы клиента вписываются в типовую конфигурацию либо маленькая перестройка процесса под возможности программы не принесет ущерба для бизнеса. хороший пример – «1С:Бухгалтерия 8» (конфигурации 2.0 и 3.0), которая предназначена для ведения бухучёта. За годы массовых внедрений эта программа была так отшлифована, что как правило для эластичной настройки вмешательств в код не нужно.

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

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

А. К.: Думаю, для всех типовых бизнес-процессов организации удачнее использовать типовое ответ. Это стремительнее и дешевле. Примерами помогать часть и бухучет процессов по управлению персоналом.

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

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

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

4. Какие конкретно риски адаптаций ПО принципиально важно учитывать?

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

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

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

  • Прозрачность. Неизменно стараемся максимально полно и объективно растолковать клиенту минусы и плюсы того либо иного варианта, вероятные последствия выбора, трудоёмкость и риски.
  • Безопасность. Она обеспечивается за счет следования стандартам вендора, разработчика платформы. Мы сохраняем предельное число типовых функций, в обязательном порядке сохраняем механизм обновлений и максимально полно документируем все трансформации, каковые вносим.
  • Пошаговость доработок. Это указывает возможность проверить согласие с клиентом, начав с маленькой задачи. Доработки отличаются от разработки под ключ модульностью, тем, что возможно поменять и додавать функции неспешно, одну за второй. В случае если IT-подрядчик настаивает на «оптовой» адаптации, это предлог насторожиться.

IT-менеджмент14170 79

Как и в то время, когда переводить IT на новый уровень

IT-менеджмент1955 7

В чем отличие между «дорогим калькулятором» и действенным IT-ответом

Разварки спустя 10000 км плюсы и минусы[PVS][FullHD]


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer