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


+ Ответить в теме
Показано с 1 по 2 из 2

Тема: Выбираем типовое решение для автоматизации бизнес-процессов предприятия

  1. #1
    Junior Member
    Регистрация
    19.12.2010
    Сообщений
    1
    Сказал(а) спасибо
    0
    Поблагодарили 0 раз(а)
    в 0 сообщениях

    По умолчанию Выбираем типовое решение для автоматизации бизнес-процессов предприятия

    Хотим типовое решение без доработок.

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

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

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

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

    А ведь выбирается типовое решение - т.е. коробочный продукт, который предполагается использовать на предприятии. Но коробочный продукт - это только "исходная точка", задающая вектор развития системы. Где гарантия, что из выбранного коробочного продукта в вашем случае удастся с приемлемым результатом построить систему, которая оправдает понесенные на нее расходы? Что доработки типового решения, выполненные конкретной командой внедрения, не пойдут в разрез с заложенной в него бизнес-логикой?

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

    Клиенты стремятся "не изобретать велосипед", а использовать типовые решения, расчитывая на высокое качество головного вендора и его надежность. Насколько оправданы такие ожидания?

    Дело в том, что любое типовое решение при внедрении дорабатывается, и становится в какой-то степени "заказным". Переход от полностью "заказной" системы к полностью типовой - плавный! Чем меньше подходит выбранная система предприятию, тем в большей степени она будет "заказной" после всех необходимых доработок.

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

    Отсюда аксиома:

    "Внедрить" на конкретном предприятии для решения определенных бизнес-задач можно, при большом желании и определенной настойчивости любое типовое решение. Особенно это относится к решениям на платформе 1С (не в этом ли секрет распространенности 1С в России?).

    Можно внедрить "1С:Бухгалтерию" для решения задач планирования производства. А можно "Управление торговлей" приспособить для финансового планирования...

    Пару - другую рук и мозгов умелых программистов и постановщиков и все будет работать!

    Вопрос только в том какое качество будет у такой "заказной" системы. Каковы будут перспективы ее развития и гибкость. И во что такая разработка обойдется по расходам - платить программистам придется Заказчику. Что хорошо для программистов - есть где воплотить полет фантазии и при чем за деньги клиента.

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

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

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

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

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

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


    Какие именно доработки вредны для системы?

    При выборе потребители рассматривают типовые решения на предмет минимальных доработок - это критерий. Но не всегда принимается во внимание, каков характер выполняемых доработок! Далее рассмотрим на сколько это важно.

    Понятно, что минимизация доработок - не самоцель.

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

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

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

    Пытаться проанализировать все это хозяйство "в лоб" - довольно затруднительно и по силам только IT-специалисту с глубокими знаниями как предприятия, так и типового решения. Как быть? Есть простой алгоритм.

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

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

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

  2. #2
    Junior Member
    Регистрация
    18.09.2012
    Сообщений
    1
    Сказал(а) спасибо
    0
    Поблагодарили 0 раз(а)
    в 0 сообщениях

    По умолчанию

    Для более функционального рисования бизнес процессов в 1С подходит программа ОптимаСофт:Схемы.
    На их главной странице лежат картинки с примерами

+ Ответить в теме

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

     

Похожие темы

  1. Как закрыть 44-й в комплексной автоматизации
    от maverick в разделе Комплексная автоматизация, КА
    Ответов: 2
    Последнее сообщение: 24.02.2017, 22:03
  2. Как использовать ресурсы корпоративной IP телефонии в целях автоматизации?
    от PolarElf в разделе Другие решения по автоматизации
    Ответов: 0
    Последнее сообщение: 31.01.2011, 08:53
  3. Ключи защиты HASP: решение проблем
    от maverick в разделе 1C:Общие вопросы
    Ответов: 0
    Последнее сообщение: 22.11.2010, 23:25
  4. ПО Microinvest для автоматизации магазинов, кафе, ресторанов
    от jyar в разделе Другие решения по автоматизации
    Ответов: 0
    Последнее сообщение: 23.03.2010, 15:08

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения


Навигация по сайту:
, 1c, 1с 8.2, 1с 8.3, Скачать 1с, 1с бухгалтерия, 1с предприятие, Программа 1с,
1с торговля, 1с управление, 1с зарплата, Обновление 1с, Миста, Программирование 1с,

Положение об ответственности
Связь с администрацией erpsolution.ru@yandex.ru