Тема 5.4 — Планирование ресурсов предприятия (ERP)

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

Почему это важно в здравоохранении и уходе#

Цифровая трансформация в здравоохранении и уходе получает внимание благодаря клиническим системам — электронной медицинской карте, общей записи ухода, приложению для пациентов. Но ничто из этого не работает без непривлекательного административного тыла под ними. Персонал нужно нанимать, ставить в график и платить ему; поставщиков нужно заключать с ними договоры и рассчитываться; лекарства, изделия и расходные материалы нужно заказывать и отслеживать; а каждый фунт должен быть учтён в рамках жёстко ограниченных общественных бюджетов. ERP — место, где это происходит, и когда она отказывает, последствия мгновенны: неоплаченный персонал, остановленные закупки, несверенные счета и финансовая функция, летящая вслепую.

Масштаб огромен. NHS Shared Business Services (NHS SBS), совместное предприятие, созданное в 2004 году, ведёт национальную финансовую и закупочную платформу на базе Oracle, обрабатывающую миллионы счетов и ведающую очень большой долей всех расходов NHS для более чем ста организаций NHS (см. Ключевые источники). Решения по ERP поэтому — не узкая финансовая забота: они формируют управление рабочей силой, контроль общественных денег и качество данных, от которого зависит любой нижестоящий анализ. Для руководителя ERP одновременно фундаментальный катализатор и одна из самых рискованных программ, которые организация когда-либо предпримет.

Ключевые понятия#

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

Система учёта (system of record). ERP — авторитетный источник финансовых данных и данных о ресурсах: книга, которой доверяют аудиторы, и расчёт заработной платы, по которому платят персоналу. Другие системы могут хранить операционные копии, но ERP — версия истины о деньгах и, часто, о существенной кадровой записи.

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

Распространённые платформы в здравоохранении и государственном секторе. В NHS и более широком британском государственном секторе основные платформы ERP — Oracle (доминирует, в основном через NHS SBS и консорциумы вроде NEP), SAP, Unit4 (широко выбираемая трастами, университетами и местными органами власти) и Microsoft Dynamics 365. Местные органы власти, оказывающие социальный уход для взрослых, ведут системы того же класса для своих финансов и закупок. Современное направление — облачная ERP (программное обеспечение как услуга), а не установки на собственных серверах.

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

Лучшие практики#

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

2. Принимайте стандарт; минимизируйте кастомизацию. Конфигурируйте ERP по стандартному шаблону поставщика или консорциума везде, где процесс подлинно массовый, и оставляйте индивидуальные изменения для редкого настоящего отличия. Тяжёлая кастомизация раздувает стоимость, губит возможность обновления и возвращает местный беспорядок, от которого вы пытались уйти: облачная ERP особенно наказывает инстинкт «сделайте, чтобы выглядело, как наша старая система».

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

4. Ведите замену ERP как крупную программу с управлением изменениями в её основе. Внедрение ERP — программа бизнес-изменений, случайно включающая ПО, а не ИТ-проект. Обеспечьте её программной дисциплиной (см. тему 5.2 — Управление программами) и настоящими усилиями по управлению изменениями (см. тему 8.1 — Управление изменениями), потому что большая часть боли ERP — люди и процессы, а не технология.

5. Будьте честны о риске программы ERP. У крупных внедрений ERP заслуженная репутация превышения сроков и стоимости и недопоставки выгод; литература о провалах обширна и межотраслевая. Закладывайте резерв, избегайте запуска «большим взрывом», где возможен поэтапный подход, и никогда не позволяйте оптимистичному графику перекрыть готовность: сдвинутую дату можно наверстать, а испорченное переключение расчёта заработной платы или книги — нет.

6. Защищайте запуск и период после него. Детально планируйте перенос данных, параллельную работу, сверку и поддержку повышенного внимания (hypercare) и сопротивляйтесь давлению сократить их. Недели вокруг запуска — когда поставщикам не платят и ломается закрытие месяца; хорошо укомплектованный период стабилизации — разница между трудным началом и публичным кризисом.

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

8. Взвешивайте общие услуги и облачную ERP по реальным компромиссам. Общие платформы (NHS SBS, консорциумы типа NEP) и облачная ERP предлагают стандартизацию, масштаб, непрерывные обновления и более лёгкое местное бремя ценой части местной гибкости и зависимости от поставщика. Выбирайте осознанно: для большинства организаций выигрыш стандартизации перевешивает потерянную гибкость, но решение нужно принимать с открытыми глазами, а не по умолчанию.

Вопросы для обсуждения с командой#

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

2. Где мы подлинно соблазняемся кастомизировать ERP, чтобы сохранить знакомый процесс, и является ли это отличие настоящим дифференциатором или просто старым беспорядком, от которого мы пытаемся уйти? Тяжёлая кастомизация — классическая ловушка корпоративной ERP: она раздувает стоимость, губит возможность обновления и возвращает ту самую местную фрагментацию, которую программа должна была убрать, а облачная ERP особенно наказывает инстинкт «сделайте, чтобы выглядело, как наша старая система». Этот вопрос просит команду быть конкретной в том, какие процессы она будет настаивать подгонять под ПО, и обосновать каждый жёстким тестом: настоящий дифференциатор или просто удобная привычка. Обсуждение важно, потому что в здравоохранении и уходе почти каждый административный процесс — главная книга, одобрения закупок, администрирование расчёта заработной платы — подлинно массовый, так что честное умолчание должно быть принять стандартный шаблон поставщика или консорциума и менять процесс, а не ПО. Конкретные ракурсы — перечислить каждую запрошенную кастомизацию и спросить, кому она выгодна, какую стоимость обновления она фиксирует и обходится ли без неё соседний траст на том же шаблоне. Хороший ответ отличает редкое законное исключение от многих запросов, продиктованных неприятием изменений, и признаёт, что принятие стандарта — проблема управления изменениями и лидерства, а не техническая. Он должен также столкнуться с долгосрочной ценой: каждое индивидуальное изменение — налог, платимый при каждом будущем облачном релизе.

3. Честно ли мы обеспечили человеческую и процессную сторону этого изменения ERP — переключение, параллельную работу, hypercare, обучение и интеграционное тестирование — или тихо ведём его как ИТ-проект? Литература о провалах однозначна: большая часть боли ERP — люди и процессы, а не технология, так что этот вопрос показывает, является ли программа подлинным усилием бизнес-изменений или ИТ-заменой в одежде программы. Период вокруг запуска — когда поставщикам не платят, ломается закрытие месяца, а персоналу платят с опозданием, и каждое из этого в органе общественного здравоохранения — не трудное начало, а разрушающий доверие, потенциально новостной провал. Напряжение для обсуждения — постоянное давление сократить параллельную работу, ужать команду hypercare и сжать график, чтобы уложиться в навязанную дату, против реальности: сдвинутую дату можно наверстать, а испорченное переключение расчёта заработной платы или книги — нет. Полезные ракурсы — пройти по каждой интеграции (электронное расписание, ESR, аптечные запасы, банк, аналитика) и спросить, какие протестированы от начала до конца, а какие предполагаются, и действительно ли владельцы процессов в финансах, закупках и кадрах командированы для перепроектирования своих процессов. Честный ответ показывает названные ресурсы управления изменениями, обучения и сверки в плане, а не строку «ИТ справится», и готов поэтапно вводить запуск там, где переключение «большим взрывом» добавляет избежимый риск. Он должен также признать, что решение продолжать должна определять готовность, а не календарь.

4. В вопросе общих услуг и облачной ERP взвесили ли мы стандартизацию, которую получим, против местной гибкости, которой пожертвуем, и приняли ли это решение осознанно, а не по умолчанию? Общие платформы, такие как NHS SBS и консорциумные экземпляры Oracle Cloud, и облачная ERP шире дают реальные призы — экономию масштаба, непрерывные обновления, более лёгкое местное бремя внедрения и поддержки, — но покупают их ценой подлинной потери местного контроля и жёсткой зависимости от дорожной карты и ритма релизов поставщика. Этот вопрос заставляет команду назвать, какая гибкость ей на самом деле важна, и проверить, стоит ли она цены самостоятельного ведения, обновления и отдельной поддержки своего административного тыла. Напряжение в обстановке здравоохранения и ухода обострено тем, что большинство административных процессов массовые, так что выигрыш стандартизации обычно перевешивает потерянную гибкость, но «обычно» — не «всегда», а дрейф в общую платформу без изучения компромисса — способ, которым организации приходят к недовольству шаблоном, который никогда сознательно не выбирали. Конкретные ракурсы — спросить, какие местные процессы команда боролась бы за сохранение и почему, что происходит, когда консорциум меняет шаблон под ними и понятны ли условия выхода и переносимости данных до подписания. Сильный ответ рассматривает это как стратегический выбор с открытыми глазами, взвешивающий зависимость от поставщика и риск дорожной карты против масштаба и облегчения обновлений, а не либо по умолчанию выбирающий общий вариант, потому что он модный, либо цепляющийся за индивидуальную платформу по привычке.

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

6. Честны ли мы по-настоящему о риске программы ERP — послужном списке сектора по превышению сроков и недопоставке — и построили ли мы график, резерв и подход к запуску вокруг этой реальности, а не оптимистичного плана? У крупных внедрений ERP заслуженная межотраслевая репутация превышения сроков и стоимости и недопоставки выгод, и этот вопрос спрашивает, усвоила ли команда эту литературу о провалах или тихо полагает, что станет исключением. Ставки в органе общественного здравоохранения беспощадны: сдвинутую дату можно наверстать, но испорченное переключение расчёта заработной платы или книги — новостное, разрушающее доверие событие с парламентскими и прессовыми последствиями, так что оптимизм, перекрывающий готовность, — не смелость, а безрассудство. Напряжение для обсуждения — постоянное давление — от навязанных дат, невозвратных затрат и желания показать прогресс — сжать график, истончить резерв и предпочесть запуск «большим взрывом» поэтапному, который был бы безопаснее, но медленнее. Конкретные ракурсы — спросить, что план предполагает пойдёт верно, где на самом деле находится резерв, возможно ли поэтапное переключение и каковы явные критерии задержки запуска, если готовности нет. Хороший ответ называет конкретные риски, которые несёт эта программа, а не отмахивается общим риском ERP, закладывает реальный резерв и защитимое решение о поэтапности и считает основанное на данных «ещё нет» законным и ожидаемым исходом, а не провалом нервов.

На практике: пример из здравоохранения и ухода#

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

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

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

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

Секторные линзы#

Стартап#

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

Малый бизнес#

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

Предприятие#

Крупный траст или фирма технологий здравоохранения ведёт полную интегрированную ERP как критичную для миссии систему учёта, а её замена — одна из самых рискованных программ, которые она когда-либо предпримет. Соблазн предприятия — тяжёлая кастомизация ради сохранения знакомых унаследованных процессов; дисциплина — принять стандартный шаблон, обеспечить ресурсами серьёзный рабочий поток качества данных и вести запуск с параллельной работой и хорошо укомплектованным периодом hypercare. Интеграции множатся — электронное расписание, ESR, аптечные запасы, банки, аналитика, — и каждая — разрушающий доверие провал, если молча ломает расчёт заработной платы или сверку закрытия месяца. Поскольку большая часть боли — люди и процессы, а не технология, управление изменениями (см. тему 8.1 — Управление изменениями) — то место, где программа предприятия выигрывается или проигрывается. Подотчётность перед советом и аудиторами делает испорченное переключение книги или расчёта заработной платы инцидентом управления, а не просто ИТ-неудачей.

Правительство#

В национальном масштабе и масштабе общих услуг ERP — инструмент стандартизации: NHS Shared Business Services и консорциумные экземпляры Oracle Cloud существуют, чтобы дать многим организациям одну шаблонную платформу, обменивая местную гибкость на экономию масштаба и непрерывные обновления. Государственная подотчётность добавляет проверку публичных закупок (конкурентные рамки, гарантии ценности за деньги) к каждому крупному решению по ERP, а национальный провал переключения имеет парламентские и прессовые последствия. Реальный рычаг центра — созыв: вменение или стимулирование общих платформ, чтобы десятки трастов и местных органов власти не вели, не обновляли и не проваливали по отдельности каждый свой административный тыл. Определяющее напряжение — между национальной стандартизацией и местной автономией: надавите на шаблон слишком сильно — принятие застрянет в обиде; слишком мягко — фрагментация, которую должна убрать ERP, тихо сохранится.

Типичные виды отказов#

• Грязные мастер-данные, перенесённые оптом. Старые дубликаты и несогласованности переносятся в новую систему, портя отчётность с первого дня. Исправление: очищайте и управляйте мастер-данными до миграции и владейте ими после.
• Кастомизация ради воспроизведения старой системы. Индивидуальные изменения, сделанные, чтобы избежать изменения процесса, раздувают стоимость и губят возможность обновления. Исправление: примите стандартный шаблон; меняйте процесс, а не ПО.
• ERP как ИТ-проект. Отношение к ней как к технологической замене обделяет усилия по изменениям, обучению и перепроектированию процессов. Исправление: ведите её как программу бизнес-изменений с настоящим управлением изменениями (тема 8.1).
• Оптимистичный запуск «большим взрывом». Сжатые графики и единое переключение превращают обычные проблемы в публичные кризисы. Исправление: поэтапно, где возможно, и никогда не обменивайте готовность на дату.
• Сломанные интеграции. Непроверенный канал «расписание — расчёт заработной платы» или «закупки — книга» платит людям неверно или ломает сверку. Исправление: наносите на карту, закрепляйте за владельцами и тестируйте от начала до конца каждый интерфейс.
• Теневые таблицы выживают. Местные обходные пути сохраняются рядом с ERP, вновь фрагментируя данные. Исправление: сделайте ERP единой системой учёта и выведите тени.

Модель зрелости#

Контрольный список#

• План счетов, поставщики, позиции и кадровые мастер-данные очищены и дедуплицированы до миграции.
• Постоянное владение мастер-данными и управление ими назначены и профинансированы.
• Внедрение определено и обеспечено ресурсами как программа бизнес-изменений, а не ИТ-проект.
• Кастомизация минимизирована; для массовых процессов принят стандартный шаблон поставщика или консорциума.
• Каждая интеграция (расписание, расчёт заработной платы/ESR, клиническая/аптечная, банковская, аналитическая) нанесена на карту, закреплена за владельцем и протестирована от начала до конца.
• Подход к запуску (большой взрыв против поэтапного/модульного) выбран по готовности, а не по навязанной дате.
• Перенос данных, параллельная работа, сверка и период hypercare запланированы и укомплектованы.
• Управление изменениями, обучение и перепроектирование процессов явно обеспечены ресурсами (см. тему 8.1).
• Варианты общих услуг и облачной ERP оценены по реальным компромиссам стандартизации и гибкости.
• ERP установлена как единая система учёта, а теневые таблицы выведены.

Ключевые источники#

• NHS Shared Business Services (NHS SBS) — национальная общая услуга по финансам и закупкам на базе Oracle для организаций NHS. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — масштаб национальной финансовой платформы NHS. https://www.oracle.com/uk/
• NHS North of England Commissioning / консорциум NEP — шаблонная облачная ERP Oracle для членов NHS. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP для трастов NHS, местных органов власти и университетов. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — финансовые процессы, лежащие в основе ERP. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — система рабочей силы и расчёта заработной платы NHS, с которой ERP должна интегрироваться. https://www.electronicstaffrecord.nhs.uk/
• См. также тему 5.2 — Управление программами, тему 5.3 — Управление корпоративным портфелем проектов и тему 8.1 — Управление изменениями.

Литература#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/