Back office программа что это такое

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

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

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

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

КАК ДИСПЕТЧЕР РЕЖЕТ RATE CONFIRMATION. BACK OFFICE/PART II

Картинка с фрагментом обсуждаемой инфраструктуры:

Итак, начнём с простого.

Рабочие места: компьютер с кнопками (порядка 90-100 шт) на каждое рабочее место. Желательно так же внешний/второй/третий монитор. Обычно используются ноутбуки, весьма широко — макбуки. Пользователи имеют админа или sudo на своих машинах, сами определяют себе комплект удобного ПО, включая редактор, отладчик, почтовый клиент, браузер, терминалку и т.д.

Интернет. Обычно в офисе WiFi и BYOD (другими словами, свободно приносимые свои собственные ноутбуки, планшеты и телефоны, злоупотребляющие офисным WiFi’ем). Часто проводной сети может вообще не быть. Безопасность в такой сети условная, потому что все коммуникации идут зашифрованными. Интернетов надо много.

И не только для котиков на ютубе в рабочее время, но и для внезапно срочно «прямо сейчас скачать DVD с сырцами, чтобы сравнить версию пакета». Из реальной жизни, кстати. С учётом всяких stackoverflow и прочих айтишных ресурсов, интернет должен быть неограниченный, неконтролируемый, и чем быстрее, тем лучше.

Проехали простое. Дальше серьёзное.

Cистема контроля версий (VCS) должна быть общей, «каждому своё» тут не прокатит. Стандарт де-факто — git, условно популярен mercurial (hg), экзотичен bazar (bzr), из прошлого века svn/cvs/vcs. Плюс у виндузятников свой мир, там что-то другое.

Система контроля версий работает локально, так что должен быть центральный репозиторий исходных кодов, в который пушат все (кто должен пушить). Весьма и весьма популярным является gitlab. Есть проприетарные решения, есть github для тех, кому лениво самому поднимать. Она же решает вторую важную вещь: pull requests.

Чтобы один человек мог посмотреть, что сделал другой до того, как оно попадёт в основную ветку (общий репозиторий). Замечу, что pull requests имеет смысл, даже если code review как таковой не проводится. Принцип простой — один написал, другой смерджил (merge).

Microsoft Office. Программы. Обзор

Если код сложный, то понадобится система для code review. Code review подразумевает, что программисты (или сисадмины — devops, всё такое) просматривают код друг друга, и существует некоторая формальная процедура принятия кода — например, «должны посмотреть и одобрить не меньше двух человек, из них один должен быть сеньёр/лид». Примеры: gerrit, Crucible. Если сложность балансирует на грани, то можно попытаться соблюдать соглашение добровольно, обсуждая в комментариях в gitlab’е. Но как всё добровольное, за чем не следят роботы, оно иногда будет давать осечки.

Управление командой людей в минимальном виде осуществляется посредством планировщика задач (task-tracker’а) — redmine, jira, mantis. Чаще всего он выполняет и роль баг-трекера. Основная цель — формализация постановки задачи, снятие неоднозначностей и нахождение виновных, когда кто-то что-то сделал не так (ты так сказал?

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

Практически обязательным можно считать наличие своей собственной вики — mediawiki, moin-moin, confluence, dokuwiki — что угодно, куда можно писать статьи, видимые другим членам команды, и где можно редактировать за другими. Идеальное место для складывания текстов «как сделать то-то», регламентов, результатов обсуждения, планируемых архитектурных решений, объяснения почему будет сделано именно так, а не иначе. Хорошо структурированная вики хорошо, но даже беспорядочная груда текстов кратно полезнее устного предания, которое затухает вместе с уволившимся сотрудником, который «всё это знал».

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

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

Писать код, который работает на рабочей станции, на которой его писали — это редкая роскошь. Чаще всего (и чем дальше, тем больше) код представляет из себя middleware — прослойку между другими крупными кусками серверного кода, и требует обширного окружения для продуктивной работы. «Этому приложению для отладки надо mysql с копией рабочей базы, memcached, redis и snmp к коммутатору». Такое окружение на рабочей станции поднимать — то ещё удовольствие. А бывает так, что проектов несколько, и у каждого своё окружение.

Таким образом, мы получаем первую сложную вещь: стенды для программистов. В реальной жизни это может быть микроконтроллер, подключенный по usb, или ферма серверов hadoop’а. Важно, что у программиста его стенд, похожий хоть в какой-то степени на рабочую конфигурацию, где программист может проверять результаты своей работы сразу, как написал.

Экономить не стоит, и у каждого программиста должен быть свой стенд. Если слишком дорого — надо поднимать мокапы, если мокапы не могут быть подняты, то у компании проблемы — программисты пишут «на продакшене», причём если программистов несколько, то одновременно. Если программистов не пускают на продакшен, то они пишут вслепую — прощай продуктивность.

Далее, есть вопрос о том, как код появляется на продакшене. Чаще всего это пакеты (deb/rpm), исполняемые файлы (exe), либо просто скучная выкладка (html). Заметим, имеет смысл даже «скучную выкладку статики» завернуть в пакет. Есть команды, которые выкладывают прямо из гита (определённого бранча, тэга, или даже мастера, с предположением, что разработка идёт в других бранчах).

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

Стандарт для opensource — jenkins. Из наиболее известных проприетарных — team city. Минимальная конфигурация просто берёт указанный бранч/тег/репозиторий и собирает пакет. Который потом можно скачать из интерфейса CI’я.

Но все привыкли к aptitude install — и для этого надо поднять свой миррор, или репозиторий пакетов. Тот же CI может выкладывать пакеты в репозиторий. Клик мышкой — и исходный код можно ставить на всех серверах, где подключен репозиторий.

Заметим, наличие репозиториев позволяет быстро «выкатывать» приложение на большом числе серверов в автоматическом или полу-автоматическом режиме, и даже иметь разделение на experimental/testing/production/oldstable. Ещё это даёт возможность очень быстро восстанавливать повреждения, так как пакетные менеджеры имеют все необходимые средства для валидации целостности установленных файлов и могут скачать пакет заново и восстановить изменённые файлы (на заметку веб-мастерам, у которых всякие злые бэкдоры в вордпрессе портят любимые php-файлы). Если при сборке нужны пакеты, которых нет в дистрибутиве, то их следует так же пакетировать. Продакшен, подъём которого зависит от аптайма pypi, это грустное зрелище. Заметим, часть зависимостей может быть актуальной только при сборке, в этом случае имеет смысл настроить репликацию используемого каталога пакетов на свои сервера.

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

Если у компании есть ресурсы, то по каждому странному багу делается тест, который его отловит. В минимальном виде нужно проверить базовые happy paths, то есть «клиент может прийти, увидеть товар, положить в корзину, оплатить и купить». Всякие sad path (у клиента нет денег/версия ядра не соответствует модулю) проверять тоже можно, но это значительно больше ресурсов. Но даже happy path тесты сильно улучшают стабильность.

Если конфигураций и тестов много, то имеет смысл поднять интеграцию системы code-review с тестами. Наиболее известный — zuul, связывающий gerrit c jenkins’ом. В этом случае предложение на code review присылается только после того, как коммит программиста (сисадмина) прошёл тесты — экономится время людей, не говоря уже о том, что львиное число простых багов отлавливается на этапе «борьбы с gerrit’ом». Идеальным примером того, как это работает на сотнях независимых разработчиков, является инфраструктура проекта openstack.

Если тесты настроены, code review отработан, всегда есть предыдущая версия, то имеет смысл задуматься о continuous integration, его оригинальном смысле, то есть автоматическое выкатывание изменений на продакшен сразу, как прошли тесты и code review.

Финальные аккорды

К этому обычно нужна почта, jabber (с которыми хорошо бы слинковать таск трекер и CI), возможно, рассылки. Часто имеет смысл поднять свой vpn-сервер, чтобы люди могли работать откуда угодно без затруднений с закрытыми портами и т.д.

Зачем «своё», когда есть гуглопочта? Ну, потому что когда начнут таинственно недоходить письма от nagios’а, потому что гуглю не нравятся bulk messages для group address, то борьба с гуглом может занять больше времени, чем свой почтовый сервер.

1. Это всё надо конфигурировать. По уму — система управления конфигурациями. chef, puppet, ansible, saltstack.
2. Это всё надо мониторить. Мониторинг — nagios, shinken, zabbix, icinga
3. Это всё надо бэкапить. Да-да, репозитории тоже надо бэкапить, потому что собирать по разработчикам 20-30 репозиториев с «у кого самая свежая версия» — то ещё удовольствие. А комментарии в merge request’ах вообще невосстановимы.
4. Ко всему этому нужны доменные имена, и лучше, чтобы домен или поддомен был в полном управлении отдела, чтобы с каждой новой A-записью не надо было ходить и канючить «ну добавьте мне ещё один стенд в DNS». Свой DNS открывает ещё важную возможность генерировать записи автоматически (например, для адресов ipmi-интерфейсов серверов)

Вот такое скромное хозяйство у хорошей IT-компании. Заметим, это только рабочие инструменты, тут нет никаких «каталогов пользователей» (и, вообще, вопрос авторизации не разбирался), систем контроля доступа, учёта рабочего времени, зарплат, бизнес-планирования и других вещей, которые нужны не разработчикам/сисадминам, а стейкхолдерам.

И сколько это стоит?

• Рабочее место сотрудника — 8 часов на человека (обычно учитывается в «первый рабочий день»)
• gitlab — 4-8 часов
• gerrit — 16-24 часа
• jenkins (база) — 2-4 часа
• jenkins (сборка пакетов) — 1-32 часа на репозиторий (зависит от репозитория и количества уже поднятых — первые поднимать тяжело, дальше проще)
• собственный репозиторий — 2-4 часа
• wiki — 1-16 часов
• блог-система — 2-4 часа
• таск-трекер — 1-8 часов
• стенды для программистов — .
• стенды для тестов — .
• настройка запуска тестов (при условии их наличия) — 1-2 часа
• zuul — 2-16 часов
• jabber-сервер — 1-4 часа
• почтовый сервер — 0.5-12 часов (в зависимости от размеров и роли)
• Рассылки — 1-3 часа
• система управления конфигурацией — x2 от каждого пункта (кроме сборки пакетов)
• бэкап — ~1 час на каждый сервис
• dns к этому всему +1 час

При условии, что будет выделяться примерно 30% рабочего времени на собственную инфраструктуру (это много), то внедрение с нуля займёт от трёх месяцев до года. Это при постоянном энтузиазме, если возникают паузы, время увеличивается (непропорционально времени простоя, потому что всё вокруг меняется и после паузы придётся много переделывать). Ещё раз взяв с того же потолка зарплату, учтя отпуска/больничные/авралы, получаем порядка 1-2 миллионов рублей, без стоимости железа, электричества и лицензий, только за работу (цифра учитывает расходы на «белые» налоги и сборы).

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

Сколько на это нужно серверов? Ответ сильно зависит от тестовых конфигураций, если мы предположим, что тестовая конфигурация — это мелкий LAMP-сервер (1Гб памяти на всё про всё), то при плотной упаковке виртуалок можно обойтись 2-5 серверами (~200-300 т.р. на каждый) для всего, плюс отдельный бэкап-сервер. Ах, да, допишите в список работ по настройке, ещё поддержание этой стопки виртуалок и виртуализаторов.

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

А оно точно нужно?

Можно ли сэкономить и не делать?

Более того, ничего фатального не произойдёт. Однако, некоторые рабочие процессы будут дольше, некоторые будут утомительными (отправка по почте друг другу zip’ов с изменениями), ряд сотрудников будет вынужден присутствовать в офисе для того, чтобы что-то сделать (например, согласовать изменения в коде), болезнь одного из сотрудников может сильно затруднить жизнь других (а кто у нас тут был, кто знал как правильно изменения выкатывать?).

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

Как все капитальные инвестиции в эффективность труда, эти все системы не являются обязательными. В конце-концов, ракеты в космос успешно запускали с какой-то там попытки и без git’а с code review и тестами.

Заключение

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

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

Заметим, если незнание гита можно считать аналогом безграмотности или невнятной речи, то есть, программист, который не умеет пользоваться гитом, либо очень «специальный» (1С, SAP), либо не очень программист, то «незнание» gerrit’а вполне понятно и потребует обучения. Чем выше уровень интеграции процессов, тем больше шансы, что критическая масса сотрудников просто не захочет учить так много. В отличие от бухгалтерш, сисадмины и программисты обучаемы довольно быстро, но если «быстро» не получается, то сопротивление может быть куда большее, чем возмущённые стоны от смены версии 1С. Нет ничего страшнее, чем ключевой технический персонал, возмущённый обязательным внедрением неудачного технического решения.

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

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

P. S. Ах да, чуть не забыл — в списке оборудования — ещё нужен принтер в офис, чтобы заявления на отпуск распечатывать.

• backoffice
• инфраструктура
• continuous integration
• code review
• version control systems
• спасибо за чтение

Источник: habr.com

Как не разориться на бэк-офисе микро- и малому бизнесу

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

71 просмотров
Бэк-офис: что это

Бэк-офис — это внутренние органы компании, которые помогают бизнесу нормально развиваться. Клиентам работа бэк-офиса обычно не видна, но они сразу ощутят, если там произойдет сбой.

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

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

Бэк-офис: зачем нужен

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

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

Если упрощать, выглядит это так: вы думаете, где брать клиентов и как развивать продукт, как организовать продажи и маркетинг, как найти надежных поставщиков и какой товар закупить. А бэк-офис думает:

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

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

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

Бэк-офис: в чем проблема

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

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

Полностью автоматизировать бэк-офис очень сложно и вряд ли получится. Ту же первичку (договоры, акты, счета-фактуры и прочее) сервисы распознают только на 80%. А если вы приучили подрядчиков отправлять вам сканы по Whatsapp, эти документы ни один сервис распознать не сможет, потому что мессенджер сильно съедает качество файлов. Знаем, сами сталкивались. Плюс сам сервис еще нужно связать с 1С, ЭДО, ЭЦП и учетными программами, которые есть в компании.

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

1. Эксперт по налоговому и бухгалтерскому учёту, который будет учитывать жизнь предприятия и следить за налоговой динамикой — 80 000 руб. в месяц

2. Финансовый директор или экономист, который мониторит эффективность бизнеса и показывает, сколько денег вы заработали, считает вашу unit-экономику — 100 000 руб в месяц.

3. Юрист, который грамотно составит договоры, соглашения и прочее и сделает так, чтобы эти договоры работали на вас — 80 000 руб в месяц.

4. Специалист техподдержки, который настроит под вас учетные программы — 100 000 руб в месяц.

5. Специалист по первичным документам, который будет учитывать всю первичку от поставщиков, покупателей и других контрагентов — 60 000 руб в месяц.

6. Специалист по расчету зарплаты, который занимается всеми выплатами сотрудникам — 80 000 руб в месяц.

7. Кадровик, который занимается документооборотом и знает не только, как вести кадровый учет, но и как правильно составить трудовой договор, чтобы защитить вашу компанию от нечистых на руку сотрудников — 80 000 руб в месяц.

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

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

Бэк-офис: какое решение предлагаем мы

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

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

Приложение для бэк-офиса

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

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

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

Введение в Microsoft Azure и Microsoft Cloud | Из этого руководства вы узнаете, что такое облачные вычисления и как Microsoft Azure может помочь вам перенести и запустить свой бизнес из облака.

Techopedia объясняет приложение для бэк-офиса

Офисные приложения Purchaseing Back могут быть различными и в зависимости от поставщиков не так хорошо (или вообще часто) переноситься друг на друга в зависимости от используемых технологий.

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

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

Диапазон функций бэк-офиса может включать в себя:

• Управление запасами
• Учет
• Отдел кадров
• Управленческая отчетность
• Контроль качества
• Главное административное управление
• CRM (система управления взаимоотношениями с клиентами)

Поставщики предлагают варианты, которые делают бэк-офис настраиваемым, поскольку он часто предоставляется в модульном формате или с совместимыми приложениями, связанными вместе, такими как в Microsoft Office.

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

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

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

Источник: ru.continuousdev.com