СИСТЕМА И СПОСОБ УПРАВЛЕНИЯ ВЫПОЛНЯЕМЫМ СТОРОННИМИ ИСПОЛНИТЕЛЯМИ ПРЕДОСТАВЛЕНИЕМ УСЛУГ ПО СОГЛАШЕНИЮ ОБ УРОВНЕ ОБСЛУЖИВАНИЯ
SYSTEM AND METHOD FOR MONITORING SERVICE LEVEL AGREEMENT BY THIRD PARTY

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ
Настоящая заявка на патент притязает на приоритет предварительной заявки на патент США №60/704,352, зарегистрированной 1 августа 2005 года, и включает ее в себя по ссылке. Настоящая заявка на патент включает в себя по ссылке следующие заявки на патент: заявку на патент США №10/262487, зарегистрированную 30 сентября 2002 года (67737-532USPT); заявку на патент США №10/412096, зарегистрированную 10 апреля 2003 года (67737-532USP1); заявку на патент США №10/797556, зарегистрированную 10 марта 2004 года (67737-532USP2); заявку на патент США №10/141801, зарегистрированную 9 мая 2002 года (67737-542USPT); заявку на патент США №10/128751, зарегистрированную 24 апреля 2002 года (67737-543USPT); и заявку на патент США №11/071831, зарегистрированную 2 марта 2005 года (67737-1002USPT).
УРОВЕНЬ ТЕХНИКИ
Область техники
Настоящее изобретение имеет отношение к системе и способу для облегчения снабжения, логистического планирования, использования трудовых ресурсов, размещения заявок на предоставления услуг, отслеживания оказания предоставляемых услуг, обработки данных финансовых операций и анализа по поддержке принятия решений, относящихся к выполняемым сторонними исполнителями поставкам услуг по соглашению об уровне обслуживания (SLA) или другим требованиям по услугам или оборудованию третьих сторон.
История предшествующего уровня техники
Многие предприятия вовлечены в деловую деятельность, которая сосредоточена на предоставлении услуг или товаров для клиентской базы. Предприятия, которые предоставляют услуги или товары конечным клиентам, называются первичными поставщиками услуг по соглашению SLA, в то время как конечные клиенты, которым предоставляются товары или услуги, называются клиентами соглашения SLA. В некоторых случаях предоставление услуг или товаров логистически администрируется через общее техническое обслуживание или гарантийное соглашение. В других случаях природа инфраструктуры, поддерживаемой первичным поставщиком услуг по соглашению SLA, является критической и не может поддерживаться посредством общего технического обслуживания или гарантийного соглашения, поскольку длительные вынужденные простои были бы слишком дорогостоящими для клиента соглашения SLA, как это может иметь место, например, при неисправной компьютерной системе, сети передачи данных или линии серийного производства. Для таких критических потребностей поддержки общей практикой для первичного поставщика услуг по соглашению SLA и клиента соглашения SLA является управление условиями поддержки услуг через соглашение об уровне обслуживания (соглашение SLA).
В прошлом обеспечение соглашения SLA обычно осуществлялось собственными силами первичного поставщика по соглашению SLA, предоставляющего услуги или товары, и такая модель давала возможность первичному поставщику услуг по соглашению SLA управлять всей деловой функциональностью по соглашению SLA. Деловые функции по соглашению SLA могут включать в себя, например, логистику, управление договорами, снабжение, использование трудовых ресурсов, управление поставками и обработку финансовых данных. Современная экономическая ситуация испытала значительный сдвиг по направлению к передаче выполнения многих деловых функций по соглашению SLA поставщикам, которые подразумевают обеспечение услуг как основную компетенцию. Поставщики обычно называются вторичными поставщиками услуг по соглашению SLA. Хотя эта деловая модель дала возможность некоторым предприятиям увеличить пропускную возможность обслуживания, доходы и прибыль, введение дополнительных уровней по предоставлению услуг часто приводило к потере управления, причем чаще, чем отсутствие прибыли, для первичного поставщика услуг по соглашению SLA.
Хотя существующие усилия были минимальным образом адресованы к некоторым из деловых функций соглашения SLA, большинство подходов представляло собой точку зрения внутреннего управления. Поэтому предшествующая разработка решений не обращалась к существенным операционным, логистическим, административным проблемам и проблемам обработки данных, с которыми сталкиваются при рассмотрении обеспечения соглашения SLA сторонними исполнителями. Поэтому имеется потребность в системе и способе, посредством которых первичный поставщик услуг по соглашению SLA может осуществить больший контроль над деловыми функциями соглашения SLA с использованием квалифицированных вторичных поставщиков услуг по соглашению SLA для поставки услуг клиентам соглашения SLA.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Способ управления выполняемой сторонними исполнителями поставкой услуг по соглашению об уровне обслуживания (SLA) включает в себя конфигурирование основных данных клиента соглашения SLA и вторичного поставщика услуг по соглашению SLA, обеспечение сети по предоставлению услуг вторичного поставщика услуг по соглашению SLA, администрирование сети трудовых ресурсов вторичного поставщика услуг по соглашению SLA, обработку требований по предоставлению услуг клиента соглашения SLA, обработку свидетельства об оказании услуг по соглашению SLA и обработку оплаты заказа на предоставление услуг по соглашению SLA.
Способ конфигурирования основных данных клиента соглашения об уровне обслуживания (SLA) и вторичного поставщика услуг по соглашению SLA включает в себя этапы, на которых конфигурируют библиотеку управления логистикой предоставления услуг по соглашению SLA, конфигурируют записи основных данных клиента соглашения SLA, конфигурируют записи заказа на приобретение клиента соглашения SLA и вводят в действие сеть вторичного поставщика услуг по соглашению SLA.
Способ обеспечения сети предоставления услуг вторичного поставщика услуг по соглашению об уровне обслуживания (SLA) включает в себя этапы, на которых формируют запрос (RFx) на предложения по меньшей мере из одной записи с подробными сведениями по предоставлению услуг клиенту соглашения SLA, отправляют запрос (RFx) на предложения в предустановленный список вторичных поставщиков услуг по соглашению SLA, предоставляют вторичным поставщикам услуг по соглашению SLA возможность формировать ответ на запрос (RFx) на предложения в ответ на получение запроса (RFx) на предложения, обрабатывают по меньшей мере один ответ на запрос (RFx) на предложения вторичных поставщиков услуг по соглашению SLA, обрабатывают по меньшей мере одно требование на приобретение вторичного поставщика услуг по соглашению SLA в ответ на прием ответа на запрос (RFx) на предложения и обрабатывают по меньшей мере один заказ на приобретение вторичного поставщика услуг по соглашению SLA в ответ на прием заполненного требования на приобретение.
Способ администрирования сети трудовых ресурсов вторичного поставщика услуг по соглашению об уровне обслуживания (SLA) включает в себя этапы, на которых выбирают по меньшей мере одно представление трудового ресурса, присоединенного к заказу на приобретение вторичного поставщика услуг по соглашению SLA, вводят в действие по меньшей мере один персонал предоставления услуг трудовых ресурсов, обрабатывают информационные параметры (установки) календаря доступности для работы по умолчанию по меньшей мере для одного персонала предоставления услуг трудовых ресурсов, предоставляют возможность администрирования календаря доступности человеческих ресурсов не по умолчанию и обрабатывают информационные параметры календаря доступности для работы не по умолчанию.
Способ обработки требований по предоставлению услуг клиента соглашения об уровне обслуживания (SLA) включает в себя этапы, на которых обрабатывают запрос на предоставление услуг клиента соглашения SLA, обрабатывают запрос на отправку услуг, обрабатывают запись уведомления об отправке трудовых ресурсов для предоставления услуг и обрабатывают принятую запись уведомления об отправке трудовых ресурсов для предоставления услуг.
Способ обработки свидетельства об оказании услуг по соглашению об уровне обслуживания (SLA) включает в себя этапы, на которых создают и сохраняют свидетельство об оказании услуг по соглашению SLA в ответ на ввод, выполненный трудовым ресурсом для предоставления услуг, обрабатывают сохраненное свидетельство об оказании услуг по соглашению SLA с помощью пользователя соответствующего вторичного поставщика услуг по соглашению SLA, обрабатывают одобренное свидетельство об оказании услуг вторичного поставщика услуг по соглашению SLA в ответ на ввод, выполненный пользователем соответствующего первичного поставщика услуг по соглашению SLA и обрабатывают одобренное свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA в ответ на ввод, выполненный пользователем соответствующего клиента соглашения SLA.
Способ обработки оплаты заказа на предоставление услуг по соглашению об уровне обслуживания (SLA) включает в себя этапы, на которых извлекают одобренные клиентом соглашения SLA свидетельства об оказании услуг, формируют файлы счетов на оплату, обрабатывают файлы счетов на оплату клиента соглашения SLA, обрабатывают оплату от клиента соглашения SLA и выдают оплату вторичному поставщику услуг по соглашению SLA.
Приведенная выше сущность изобретения не предназначена для того, чтобы представлять каждый вариант воплощения или каждый аспект настоящего изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ И ТАБЛИЦ
Более полное понимание способа и устройства настоящего изобретения может быть получено с помощью ссылки на последующее подробное описание, взятое вместе с сопроводительными чертежами и таблицами, на которых:
фиг.1 - высокоуровневое представление физической связи/сети передачи данных;
фиг.2A-2B - высокоуровневое представление системы и способа управления выполняемыми сторонними исполнителями поставками услуг по соглашению об уровне обслуживания (SLA) и без соглашения об уровне обслуживания;
фиг.3 - иллюстративная домашняя страница для пользователя первичного поставщика услуг по соглашению SLA;
фиг.4 - блок-схема последовательности операций, которая иллюстрирует высокоуровневые функциональные возможности для функции основных данных клиента соглашения SLA;
фиг.5 - блок-схема последовательности операций, которая иллюстрирует процесс для создания и сохранения в библиотеке конфигурации работника для предоставления услуг по соглашению SLA;
фиг.6 - блок-схема последовательности операций, которая иллюстрирует процесс для создания и сохранения в библиотеке материала для предоставления услуг по соглашению SLA;
фиг.7 - блок-схема последовательности операций, которая иллюстрирует процессы создания и сохранения, относящиеся к записям по предоставлению услуг по соглашению SLA;
фиг.8 - блок-схема последовательности операций, которая иллюстрирует процессы создания и сохранения, относящиеся к заказам на приобретение клиента соглашения SLA;
фиг. 9 - диаграмма, которая иллюстрирует схему базы данных, которая поддерживает функцию основных данных;
фиг.10 - блок-схема последовательности операций, которая иллюстрирует процесс подготовки ввода в систему вторичного поставщика услуг по соглашению SLA;
фиг.11 - типовой выходной отчет, детализирующий записи с подробными сведениями по предоставлению услуг по соглашению SLA, не связанные по меньшей мере с одним заказом на приобретение вторичного поставщика услуг по соглашению SLA;
фиг.12A-12B - блок-схемы последовательности операций, которые иллюстрируют высокоуровневые процессы, применимые к снабжению, выполняемому сторонними вторичными поставщиками услуг по соглашения SLA;
фиг.13 - схема базы данных, которая поддерживает функцию снабжения;
фиг.14A-14B - блок-схемы последовательности операций, которые иллюстрируют высокоуровневые процессы, применимые к управлению предоставлением услуг трудовых ресурсов;
фиг.15 - блок-схема последовательности операций, которая иллюстрирует процесс конфигурации календаря трудовых ресурсов;
фиг.16 иллюстрирует схему базы данных, которая поддерживает функцию управления предоставлением услуг трудовых ресурсов;
фиг.17A - блок-схема последовательности операций, иллюстрирующая поток процесса, применимый к логистическому обеспечению и функции администрирования;
фиг.17B изображает интерфейс, в который встроены активные элементы управления для использования вместе с потоком процесса, показанным на фиг.17A;
фиг.17C изображает интерфейс, в который встроены активные элементы управления для использования вместе с потоком процесса, показанным на фиг.17A;
фиг.18 иллюстрирует схему базы данных, которая поддерживает логистическое обеспечение и функцию администрирования;
фиг.19A-19B иллюстрируют процессы, применимые к приемке работ и гарантии качества предоставления услуг по соглашению SLA;
фиг.20 иллюстрирует схему базы данных, которая поддерживает приемку работ и гарантию качества предоставления услуг по соглашению SLA;
фиг.21 - блок-схема последовательности операций, которая иллюстрирует процессы, применимые к функции выставления и оплаты счетов;
фиг.22 иллюстрирует схему базы данных, которая поддерживает функцию оплаты счетов;
фиг.23 - макроуровневое представление функции управления информацией и поддержки принятия решений;
таблица 1 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и общие деловые данные для первичного поставщика услуг по соглашению SLA;
таблица 2 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и общая информация для пользователей, связанных с первичным поставщиком услуг по соглашению SLA;
таблица 3 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация различных типов предоставления услуг по соглашению SLA;
таблица 4 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация различных типов работников для предоставления услуг по соглашению SLA;
таблица 5 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация различных единиц измерения времени ответа для предоставления услуг по соглашению SLA;
таблица 6 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и свойства материалов по соглашению SLA;
таблица 7 - иллюстративная таблица базы данных, в которой размещаются отношения соответствия между материалами по соглашению SLA и местоположениями;
таблица 8 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и свойства физических местоположений;
таблица 9 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация типов физических местоположений, хранящихся в таблице 8;
таблицы 10-13 - иллюстративные иерархические/реляционные таблицы базы данных, в которых размещается идентифицирующая информация и отношения географических местоположений, хранящихся в системе;
таблицы 14-22 - иллюстративные иерархические/реляционные таблицы базы данных, в которых размещаются исходные данные профилирования квалификаций/атрибутов работников в системе;
таблицы 23-25 - иллюстративные таблицы базы данных, в которых размещается идентифицирующая информация профилей работников по предоставлению услуг по соглашению SLA и соответствующие квалификации/атрибуты, созданные первичным поставщиком услуг по соглашению SLA;
таблица 26 - иллюстративная таблица базы данных, в которой размещаются отношения соответствия и требования квалификации между профилями работников по предоставлению услуг по соглашению SLA и основными записями материалов по соглашению SLA;
таблица 27 - иллюстративная таблица базы данных, в которой размещается общая деловая информация относительно клиентов соглашения SLA;
таблица 28 - иллюстративная таблица базы данных, в которой размещаются соответствующие подробные сведения относительно договоров клиентов соглашения SLA;
таблица 29 - иллюстративная таблица базы данных, в которой размещаются соответствующие подробные сведения относительно пользователей клиента соглашения SLA;
таблица 30 - иллюстративная таблица базы данных, в которой размещаются соответствующие подробные сведения относительно записей предоставления услуг клиенту соглашения SLA;
таблица 31 - иллюстративная таблица базы данных, в которой размещаются соответствующие подробные сведения относительно записей материалов для предоставления услуг клиенту соглашения SLA и отношения соответствия с привязанной записью предоставления услуг, хранящейся в таблице 30;
таблица 32 - иллюстративная таблица базы данных, в которой размещаются отношения соответствия между записями предоставления услуг клиенту соглашения SLA и хранящимися в системе профилями работников по предоставлению услуг по соглашению SLA;
таблица 33 - иллюстративная таблица базы данных, в которой размещаются отношения соответствия между записями с подробными сведениями по предоставлению услуг по соглашению SLA и физическими местоположениями;
таблицы 34-36 - иллюстративные таблицы базы данных, в которых размещаются подробные сведения, относящиеся к заказам на приобретение между первичным поставщиком услуг по соглашению SLA и клиентом соглашения SLA;
таблицы 37-38 - иллюстративные таблицы базы данных, в которых размещаются подробные сведения, относящиеся к запросам (RFx) на предложения первичного поставщика услуг по соглашению SLA;
таблица 39 - иллюстративная таблица базы данных, в которой размещаются отношения соответствия между записями с подробными сведениями по предоставлению услуг клиенту соглашения SLA и запросами (RFx) на предложения первичного поставщика услуг по соглашению SLA;
таблица 40 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и общая деловая информация, применимая ко вторичным поставщикам услуг по соглашению SLA;
таблица 41 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и общая информация, применимая к пользователям вторичного поставщика услуг по соглашению SLA;
таблицы 42-46 - иллюстративные таблицы базы данных, в которых размещается идентифицирующая информация о семействах бизнеса профилей предоставления услуг работников по соглашению SLA, обеспечиваемых вторичными поставщиками услуг по соглашению SLA, и применимая к ним область географического охвата;
таблица 47 - иллюстративная таблица базы данных, в которой размещаются подробные сведения, относящиеся к запросам (RFx) на предложения, отправленным вторичным поставщикам услуг по соглашению SLA;
таблицы 48-49 - иллюстративные таблицы базы данных, в которых размещаются подробные сведения, относящиеся к ответам на запросы (RFx) на предложения вторичного поставщика услуг по соглашению SLA;
таблица 50 - иллюстративная таблица базы данных, в которой размещаются подробные сведения, относящиеся к кандидатурам на предоставление услуг трудовых ресурсов, представленным вторичными поставщиками услуг по соглашению SLA в ходе процесса ответа на запросы (RFx) на предложения;
таблицы 51-52 - иллюстративные таблицы базы данных, в которых размещаются подробные сведения, применимые к заказам на приобретение между первичными поставщиками услуг по соглашению SLA и вторичными поставщиками услуг по соглашению SLA;
таблица 53 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и подробные сведения, применимые к ресурсам работников по предоставлению услуг;
таблица 54 - иллюстративная таблица базы данных, в которой размещаются подробные сведения о назначении, применимые к индивидуальным ресурсам работников по предоставлению услуг;
таблицы 55-57 - иллюстративные таблицы базы данных, в которых размещается информация относительно доступности по календарю/времени ресурсов работников по предоставлению услуг;
таблицы 58-63 - иллюстративные таблицы базы данных, в которых размещаются базовые исходные данные, используемые системой календаря;
таблицы 64-66 - иллюстративные таблицы базы данных, в которых размещается идентифицирующая информация и подробные сведения, применимые к запросу о предоставлении услуг по соглашению SLA;
таблица 67 - иллюстративная таблица базы данных, в которой размещаются коды состояния, которые могут использоваться вместе с запросом о предоставлении услуг по соглашению SLA;
таблица 68 - иллюстративная основная таблица базы данных, в которой размещается идентифицирующая информация и основные подробные сведения, относящиеся к запросу о поставке услуг;
таблица 69 - иллюстративная таблица базы данных, в которой размещаются подробные сведения, относящиеся к наличию ресурса по соглашению SLA в связи с запросом о предоставлении услуг по соглашению SLA;
таблица 70 - иллюстративная таблица базы данных, в которой размещаются варианты предпочтения ресурса соглашения SLA, доступные для пользователя первичного поставщика услуг по соглашению SLA во время процесса, значения хранятся в таблице 68;
таблица 71 - иллюстративная таблица базы данных, в которой размещаются коды потенциальных статусов, применимые к запросу о предоставлении услуг по соглашению SLA в течение его жизненного цикла, значения хранятся в таблице 68;
таблица 72 - иллюстративная таблица базы данных, в которой размещаются конкретные подробные детали, относящиеся к запросу о поставке услуг;
таблица 73 - иллюстративная основная таблица базы данных, в которой размещается идентифицирующая информацию и основные подробные сведения, относящиеся к свидетельству о предоставлении услуг по соглашению SLA;
таблица 74 - иллюстративная таблица базы данных, в которой размещаются подробные сведения по обслуживанию, применимые к свидетельству о предоставлении услуг по соглашению SLA;
таблица 75 - иллюстративная таблица базы данных, в которой размещаются подробные сведения по материалам, применимые к свидетельству о предоставлении услуг по соглашению SLA;
таблица 76 - иллюстративная таблица базы данных, в которой размещаются типы размещения потенциального результата предоставления услуг, применимые к позиции свидетельства о предоставлении услуг по соглашению SLA;
таблица 77 - иллюстративная таблица базы данных, в которой размещаются коды потенциальных статусов, применимые к свидетельству о предоставлении услуг по соглашению SLA в его жизненном цикле;
таблица 78 - иллюстративная таблица базы данных, в которой размещаются коды размещения потенциальных показателей качества, применимые к позиции свидетельства о предоставлении услуг по соглашению SLA;
таблица 79 - иллюстративная таблица базы данных, в которой размещаются коды размещения потенциальных показателей администрирования, применимые к позиции свидетельства о предоставлении услуг по соглашению SLA;
таблица 80 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация первичных кодов отклонения, используемых клиентом соглашения SLA при обзоре свидетельства о предоставлении услуг по соглашению SLA;
таблица 81 - иллюстративная таблица базы данных, в которой размещаются подробные сведения, относящиеся к отклоненным свидетельствам о предоставлении услуг по соглашению SLA;
таблица 82 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и основная информация, относящаяся к командному файлу извлечения одобренных свидетельств по соглашению SLA;
таблица 83 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и основная информация, относящаяся к конкретным записям, связанным с командным файлом извлечения одобренных свидетельств по соглашению SLA;
таблица 84 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и основная информация, относящаяся к файлу выставления счетов клиенту соглашения SLA;
таблица 85 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и информация, относящаяся к конкретным записям, связанным с файлом выставления счетов клиенту соглашения SLA;
таблица 86 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и основная информация, относящаяся к файлу выставления счетов вторичному поставщику услуг по соглашению SLA; и
таблица 87 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация и информация, относящаяся к конкретным записям, связанным с файлом выставления счетов вторичному поставщику услуг по соглашению SLA;
таблица 88 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация различных периодов охвата предоставления услуг клиенту соглашения SLA;
таблица 89 - иллюстративная таблица базы данных, в которой размещается идентифицирующая информация типов разнообразных расходов по предоставлению услуг по соглашению SLA, которые могли быть добавлены трудовыми ресурсами в ходе предоставления услуг клиенту соглашения SLA;
таблица 90 - иллюстративная таблица базы данных, в которой размещаются значения тарифов для ответов на запросы на предложения вторичного поставщика услуг по соглашению SLA, применимые к конкретным периодам охвата предоставления услуг клиенту соглашения SLA; и
таблица 91 - иллюстративная таблица базы данных, в которой размещаются значения тарифов для ответов на запросы на предложения вторичного поставщика услуг по соглашению SLA, применимые к конкретным типам расходов по предоставлению услуг по соглашению SLA.
Специалисты в области техники поймут, что иллюстративные записи, показанные в таблицах 1-91, не являются исчерпывающим списком потенциальных значений данных. Добавление других значений данных является простой модификацией базы данных, которая может быть легко достигнута специалистом.
ПОДРОБНОЕ ОПИСАНИЕ ИЛЛЮСТРАТИВНЫХ ВАРИАНТОВ ВОПЛОЩЕНИЙ ИЗОБРЕТЕНИЯ
Различные варианты воплощения изобретения обеспечивают комплексную компьютерную систему с сетевой поддержкой и способ для предоставления возможности выполнения первичных деловых функций и управления ими, которые могут быть применены к выполняемому сторонним исполнителем предоставлению услуг по соглашению об уровне обслуживания (SLA) среди первичных поставщиков услуг по соглашению SLA, вторичных поставщиков услуг по соглашению SLA и клиентов соглашения SLA. Первичные деловые функции включают в себя управление договором, снабжение, распределение трудовых ресурсов, логистику по соглашению SLA, управление поставками по соглашению SLA, обработку финансовых данных, совместную работу систем между предприятиями и управление отчетами/информацией. Для целей настоящей заявки на патент термин "деловая функция" относится к любой из множества основных деловых деятельностей, присутствующей в оптимальных системах управления соглашением SLA, в том числе к функции основных данных, к функции снабжения, к функции управления предоставлением услуг трудовых ресурсов, к функции администрирования предоставлением услуг, к функции приемки работ и гарантии качества по соглашению SLA, к функции выставления счета/оплаты и к функции управления информацией/отчетности.
На высоком уровне устойчивая производственная деятельность в типичном варианте воплощения заключается в совместной сетевой среде обработки данных, поддерживаемой с помощью базы данных, специально выполненной для сбора, обработки данных и управления данными, применимыми к выполняемому сторонним исполнителем продукту по предоставлению услуг по соглашению SLA. Среда обработки данных, называемая средой управления предоставлением услуг по соглашению SLA, обычно включает в себя функцию основных данных, функцию снабжения, функцию предоставления услуг трудовых ресурсов, функцию администрирования предоставлением услуг, функцию приемки работы и гарантии качества по соглашению SLA, функцию выставления счета/оплаты и функцию управления информацией/отчетности.
Функция основных данных сохраняет основные данные клиента по соглашению SLA, которые применимы, например, к общей деловой информации, логистической управляющей информации, информации о договоре соглашения SLA, информации о подробных сведениях по предоставлению услуг по соглашению SLA и информации о заказах на приобретение. Функция основных данных может также сохранять библиотеку профилей квалификаций и должностных инструкций для предоставления услуг по соглашению SLA, библиотеку профилей квалификаций для предоставления услуг по соглашению SLA и матрицу соответствия подробных сведений по предоставлению услуг по соглашению SLA и профилей квалификаций для предоставления услуг по соглашению SLA.
Функция снабжения обычно осуществляет несколько функций для того, чтобы дать первичным поставщикам услуг по соглашению SLA возможность собирать и сохранять деловую информацию, применимую ко вторичным поставщикам услуг по соглашению SLA, дать первичным поставщикам услуг по соглашению SLA возможность классифицировать вторичных поставщиков услуг по соглашению SLA в терминах обеспечения квалификации по соглашению SLA и возможностей географического охвата, дать первичным поставщикам услуг по соглашению SLA возможность систематически идентифицировать и количественно определять потребности охвата клиента по соглашению SLA, как детализировано в функции основных данных, дать первичным поставщикам услуг по соглашению SLA возможность формировать систематические запросы (RFx) на предложения из записей об охвате клиентов по соглашению SLA, дать первичным поставщикам услуг по соглашению SLA возможность систематически и логически формировать списки ходатайств с предложениями вторичных поставщиков услуг по соглашению SLA для каждого созданного запроса (RFx) на предложения, дать вторичным поставщикам услуг по соглашению SLA возможность систематически формировать ответы на запросы (RFx) на предложения и при необходимости представлять подходящие трудовые ресурсы, соответствующие ответам, дать первичным поставщикам услуг по соглашению SLA возможность систематически делать обзор представленных ответов на запросы на предложения/котировку/запрос (RFx) и дать первичным поставщикам услуг по соглашению SLA возможность систематически принимать/предоставлять ответы на запросы (RFx) на предложения и создавать заказы на приобретение вторичным поставщикам услуг по соглашению SLA со ссылкой на подробные сведения ответа на запрос (RFx) о предложении.
Функция управления предоставлением услуг трудовых ресурсов обычно выполняет несколько функций, чтобы дать первичному поставщику услуг по соглашению SLA возможность обзора и одобрения размещения представленных кандидатур ответов на запросы (RFx) на предложения, дать первичному поставщику услуг по соглашению SLA возможность систематического уведомления о размещении/статусе относительно представленных кандидатур ответов на запросы (RFx) на предложения вторичного поставщика услуг по соглашению SLA, дать возможность создания записи ресурса для предоставления услуг по соглашению SLA первичным поставщиком услуг по соглашению SLA после одобрения/приема представленных кандидатур ответов на запросы (RFx) на предложения, дать вторичному поставщику услуг по соглашению SLA возможность доступа к системе трудовых ресурсов, дать возможность систематического исполнения соглашения посредством трудовых ресурсов вторичного поставщика услуг по соглашению SLA, дать возможность администрирования и конфигурирования календаря наличия работ посредством вторичного поставщика услуг по соглашению SLA и одобренных трудовых ресурсов, дать первичному поставщику услуг по соглашению SLA возможность логистической оценки обеспечения времени и дать первичному поставщику услуг по соглашению SLA возможность проактивного посредничества для периодов недоступности для трудовых ресурсов.
Функция администрирования предоставлением услуг обычно выполняет несколько функций для того, чтобы дать функциональные возможности запросов на предоставление услуг, посредством которых клиент соглашения SLA может создать и представить запрос на предоставление услуг первичному поставщику услуг по соглашению SLA, и предоставить средства запросов системы первичного поставщика услуг по соглашению SLA, которые могут быть использованы для выдачи списка сконфигурированных вторичных поставщиков услуг по соглашению SLA, а также их соответствующих расценок и наличия подходящих трудовых ресурсов, выделяемых для предоставления услуг. Критерии запроса могут быть сформированы через выборочный пользовательский ввод или систематический ввод, как в случае получения особого запроса на предоставление клиентских услуг по соглашению SLA.
Функция администрирования предоставлением услуг также обычно выполняет несколько функций для того, чтобы дать первичному поставщику услуг по соглашению SLA возможность систематически представлять запись запроса на предоставление услуг вторичному поставщику услуг по соглашению SLA, дать вторичному поставщику услуг по соглашению SLA возможность подтвердить наличие ресурсов и последующую отправку ресурса первичному поставщику услуг по соглашению SLA и дать первичному поставщику услуг по соглашению SLA возможность подтвердить отправку ресурса клиенту соглашения SLA.
Функция приемки работ и гарантии качества по соглашению SLA обычно выполняет несколько функций для того, чтобы обеспечить доступ к ресурсам вторичного поставщика услуг по соглашению SLA для функции свидетельства об оказании услуги, посредством которой вводятся подробные сведения, относящиеся, например, к выполненной работе, использованным материалам и временным затратам, в ответ на запрос предоставления услуг, дать вторичному поставщику услуг по соглашению SLA возможность предоставлять свидетельство об оказании услуги клиенту соглашения SLA для обзора и одобрения размещения, дать клиенту соглашения SLA возможность обрабатывать свидетельство об оказании услуги вторичного поставщика услуг по соглашению SLA и предоставлять информацию оценки гарантии качества и дать клиенту соглашения SLA возможность предоставлять свидетельство об оказании услуги вторичного поставщика услуг по соглашению SLA первичному поставщику услуг по соглашению SLA.
Функция выставления счета/оплаты обычно выполняет функции обработки финансовых данных, обеспечивающие сконфигурированное систематическое извлечение одобренных клиентом по соглашению SLA свидетельств об оказании услуги, систематическое формирование файлов счетов на оплату от первичного поставщика услуг по соглашению SLA клиенту соглашения SLA, систематическое формирование файлов счетов на оплату от вторичного поставщика услуг по соглашению SLA первичному поставщику услуг по соглашению SLA, средство загрузки данных квитанции об оплате первичному поставщику услуг по соглашению SLA при оплате клиентом соглашения SLA и средство выпуска платежа первичного поставщика услуг по соглашению SLA вторичному поставщику услуг по соглашению SLA при условии оплаты клиентом соглашения SLA.
Функция управления информацией/отчетности обычно выполняет функцию выдачи общей информации. Эта функция привлекает собранные данные системы для создания отчетов и анализа.
Теперь обратимся к чертежам. Фиг.1 является высокоуровневым представлением физической связи/сети передачи данных. На фиг.1 проиллюстрированы пять первичных типов узлов компьютерной сети, а именно: обозреватель или другой пользовательский интерфейс (UI), сервер сети связи, сервер приложений, модуль приложений, сервер базы данных и база данных. Хотя типичная среда включает в себя решение с поддержкой сети и размещением на главном компьютере, различные варианты воплощения могут быть перенесены по глобальной сети (WAN) при использовании внутренней сети. С минимальными модификациями в аппаратном оборудовании и прикладном программировании применение различных описанных здесь принципов не ограничено с точки зрения компьютерной среды.
На фиг.1 показано, что компьютерная система 100 включает в себя систему 150 управления снабжением/соглашением SLA, пользовательские системы 101-105, управляемые системными пользователями 110(a)-(e) через системные обозреватели 115(a)-(e), систему 120 связи по сети Интернет/интранет, сервер 155 приложений, содержащий модули 160-180 обработки данных, и систему 185 базы данных. Пользовательские системы 101-105 представляют собой вход в систему и порталы доступа, обычно представленные минимальными функциональными возможностями входа в систему и безопасности и графическим интерфейсом пользователя (GUI).
Модули 160-180 обработки данных включают в себя административный модуль 160, модуль 165 первичного поставщика услуг по соглашению SLA, модуль 170 вторичного поставщика услуг по соглашению SLA, модуль 175 работника и, например, модуль клиента соглашения SLA. Административный модуль 160 в некоторых вариантах воплощения может быть устранен, если первичный поставщик услуг по соглашению SLA должен был купить или лицензировать решение полностью и поместить систему 100 в свою собственную инфраструктуру.
Модуль 165 первичного поставщика услуг по соглашению SLA функционирует как производственный администратор для компьютерной системы 100 и в типичном варианте воплощения управляет загрузкой клиентов соглашения SLA, вторичных поставщиков услуг по соглашению SLA, пользователей приложений и работников по соглашению SLA. Специалисты в области техники поймут, что первичный поставщик услуг по соглашению SLA представляет собой производственное предприятие, которое имеет клиентов соглашения SLA, по договору должно предоставлять услуги по соглашению SLA и другие услуги, заключает договор субподряда со вторичными поставщиками услуг по соглашению SLA и в конечном счете ответственно за качество персонала для предоставления услуг по соглашению SLA и выполненной работы по предоставлению услуг по соглашению SLA.
Модуль 170 вторичного поставщика услуг по соглашению SLA поддерживает процессы взаимодействия и производственные процессы для предприятий, которые заключают договор субподряда с первичными поставщиками услуг по соглашению SLA, чтобы предоставить охват предоставления услуг по соглашению SLA. Модуль 175 работника по соглашению SLA поддерживает процессы взаимодействия и производственные процессы для отдельных работников по предоставлению услуг по соглашению SLA, которые наняты субподрядчиками - вторичными поставщиками услуг по соглашению SLA. Модуль 180 клиента соглашения SLA поддерживает процессы взаимодействия и производственные процессы для отдельных клиентов соглашения SLA, которые требуют предоставления услуг по соглашению SLA и заключают договор на него.
В различных вариантах воплощения возможности совместных процессов взаимодействия и производственных процессов осуществляют разнообразные объекты, проиллюстрированные как часть компьютерной системы 100 вместе в управляемой настройкой обработки данных в реальном времени. В отличие от этого во многих предшествующих системах в попытках управлять этой производственной деятельностью обычно использовались несколько систем. В прошлом администрирование клиентских данных и действий обычно осуществлялось в приложении управления отношениями с клиентами (CRM) или другом специализированном приложении, администрирование логистики осуществлялось в каком-либо приложении управления проектами, в то время как управление административными функциями и подробными сведениями поставщика и трудовых ресурсов обычно осуществлялось в дополнительных приложениях, если осуществлялось вообще.
Система 100 является решением с поддержкой полного жизненного цикла снабжения, управления логистикой и администрирования, которое связывает первичного поставщика услуг по соглашению SLA, вторичных поставщиков услуг по соглашению SLA и клиента соглашения SLA вместе в одну совместную рабочую среду. Система 100 служит для того, чтобы дать первичному поставщику услуг по соглашению SLA контроль над: планированием логистики предоставления услуг по соглашению SLA, уровнями квалификации ресурса для предоставления услуг, доступностью и объемом ресурсов для предоставления услуг, отправкой ресурсов для предоставления услуг по соглашению SLA, взаимодействиями процессов предоставления услуг по соглашению SLA, гарантией качества предоставления услуг по соглашению SLA и управлением прибылью от инвестиций. Кроме того, система 100 интегрирует все основные функциональные производственные процессы, такие как, но без ограничения, администрирование продавцов, снабжение, бухгалтерский учет, управление финансами и рисками, в одну среду, с тем чтобы можно было избежать использования множества несоизмеримых и дорогостоящих приложений.
Фиг.2A-2B представляют высокоуровневое полное представление системы и способа управления поставками по соглашению об уровне обслуживания (SLA) и не по соглашению SLA, выполняемыми сторонними исполнителями. На фиг.2A поток 200 процесса начинается на этапе 202. На этапе 202 первичный поставщик услуг по соглашению SLA определил или запланировал конкретные поставки по заявке на обслуживание, относящиеся к одному или более клиентам соглашения SLA в одном или более географических местоположениях. На этапе 204 конфигурируются основные данные, соответствующие клиенту соглашения SLA и вторичному поставщику услуг по соглашению SLA. На этапе 210 создаются запросы (RFx) на предложения из записей с требованиями по соглашению SLA, чтобы установить цены и ресурсные возможности потенциальных вторичных поставщиков услуг по соглашению SLA. На этапе 212 делается обзор ответов на запросы (RFx) и присуждения предложений на основе возможностей предоставления услуг и цен. На этапе 214 оговариваются окончательные цены и сроки поставки обслуживания с соответствующими поставщиками услуг.
На этапе 216 формируются единые заказы на приобретение для подходящих вторичных поставщиков услуг по соглашению SLA. На этапе 218 формируется матрица предоставления услуг по соглашению SLA, и единые заказы на приобретение для вторичных поставщиков услуг по соглашению SLA систематически присоединяются к записям основных данных по соглашению SLA. Первичный поставщик услуг по соглашению SLA поддерживает средства редактирования матрицы и может вручную построить отношения, как в случае, когда вторичный поставщик услуг по соглашению SLA идентифицируется через неконкурентный процесс предложений. На этапе 220 подходящие вторичные поставщики услуг по соглашению SLA представляют кандидатуры ресурсов первичному поставщику услуг по соглашению SLA. Одобренные ресурсы связываются с соответствующими едиными заказами на приобретение для вторичного поставщика услуг по соглашению SLA. На этапе 222 вторичные поставщики услуг по соглашению SLA уведомляются относительно одобрения трудовых ресурсов. На этапе 224 заполняется библиотека ресурсов вторичного поставщика услуг по соглашению SLA и формируется поставляемый в составе системы график наличия по дням и часам.
В этапе 226 трудовым ресурсам вторичного поставщика услуг по соглашению SLA предоставляются мандаты доступа в систему. На этапе 228 трудовые ресурсы вторичных поставщиков услуг по соглашению SLA обращаются к системе 100, выполняют соглашения и признают требования/правила доступа к клиентскому оборудованию по соглашению SLA. На этапе 230 первичный поставщик услуг по соглашению SLA готов управлять требованиями клиента соглашения SLA.
На фиг.2B исполнение переходит от этапа 230 на этап 240. На этапе 240 пользователь клиента соглашения SLA создает запрос на предоставление услуг и представляет его первичному поставщику услуг по соглашению SLA. На этапе 242 пользователь первичного поставщика услуг по соглашению SLA входит в модуль 160 администрирования соглашения SLA. На этапе 244 производится запрос к системе 100, и она возвращает список всех вторичных поставщиков услуг по соглашению SLA, которые могут обеспечить услуги по запросу (запросам) на предоставление услуг клиента соглашения SLA. На этапе 246 список поставщиков услуг отображает, например, одобренные ресурсы поставщика услуг, доступность ресурсов, ссылку на единый заказ на приобретение и оплату за обслуживание по договору и подходящую матрицу поставки. На этапе 248 выбирается запись вторичного поставщика услуг по соглашению SLA. На этапе 250 пользователь первичного поставщика услуг по соглашению SLA подает запрос на предоставление услуг вторичному поставщику услуг по соглашению SLA. На этапе 252 вторичный поставщик услуг по соглашению SLA подтверждает возможность отправки.
На этапе 254 первичный поставщик услуг по соглашению SLA отправляет подтверждение пользователю клиента соглашения SLA. На этапе 256 вторичный поставщик услуг по соглашению SLA отправляет доступные ресурсы в местоположение клиента соглашения SLA. На этапе 260 ресурсы поставщика выполняют работу в местоположении клиента соглашения SLA. На этапе 270 ресурс поставщика вводит сформированные необходимые данные в модуль хронометража/поставки по соглашению SLA. На этапе 272 свидетельство о поставке ресурса вторичного поставщика услуг по соглашению SLA представляется пользователю клиента соглашения SLA. На этапе 274 пользователь клиента соглашения SLA обрабатывает представленное свидетельство и заполняет оценку поставки. На этапе 276 свидетельство представляется первичному поставщику услуг по соглашению SLA и одобряется. На этапе 278 происходит систематическое сконфигурированное извлечение подробных сведений об одобренном свидетельстве и формируется файл предоставления счета для клиента соглашения SLA. На этапе 282 файл предоставления счета передается клиенту соглашения SLA. На этапе 284 клиент соглашения SLA осуществляет оплату первичному поставщику услуг по соглашению SLA. На этапе 286 первичный поставщик услуг по соглашению SLA осуществляет оплату вторичному поставщику услуг по соглашению SLA.
Фиг.3 - иллюстративная домашняя страница в сети для пользователя первичного поставщика услуг по соглашению SLA. На фиг.3 пользовательский интерфейс (UI) 300 разделен на два основных раздела, пользовательскую навигационную панель/меню 310 и панель 320 управления деятельностью. Навигационная панель/меню 310 является основным режимом пользовательского интерфейса (UI) для активации желаемых функциональных возможностей приложения, в то время как панель 320 управления деятельностью служит пользователю для акцента внимания или запроса конкретной производственной деятельности. Пользователь может обратиться к одним и тем же функциям и формам приложения либо через пользовательскую навигационную панель/меню 310, либо через панель 320 управления деятельностью.
Типичными информационными аспектами функции основных данных являются общая производственная информация, логистическая управляющая информация, информация о договоре по соглашению SLA и информация о подробных сведениях по предоставлению услуг по соглашению SLA. Общая производственная информация включает в себя информацию, имеющую отношение к клиенту соглашения SLA и первичному поставщику услуг по соглашению SLA. Иллюстративные таблицы базы данных, используемые для хранения общей производственной информации, включают в себя таблицы 1-2, 8-9, 27 и 29. Примеры общей производственной информации включают в себя элементы производственной информации относительно типа производственного предприятия, идентифицирующей информации объединения, операционных местоположений, размера компании, количества сотрудников и пользовательской информации. География физического местоположения определяется в терминах параметров настройки базы данных, как представлено, например, в таблицах 10-13. Эта географическая схема, которая может быть расширена, чтобы включать в себя почтовый код или другие уникальные параметры, такие как деловые районы, дает возможность определять местоположение в терминах страны, области, округа и города/населенного пункта.
Логистическая управляющая информация представляет собой основное определение модели деловой деятельности первичного поставщика услуг по соглашению SLA в терминах предоставления услуг по соглашению SLA. Имеются различные типы определенной информации, из которых одна группа информации имеет дело с типами предоставляемых услуг, типами рабочей силы для предоставления услуг, периодами времени для предоставления услуг, материалами для предоставления услуг и складами материалов для предоставления услуг. Иллюстративные таблицы базы данных, используемые для хранения логистической управляющей информации, включают в себя таблицы 3-7 и 88-89.
Значения данных, используемые конкретным первичным поставщиком услуг по соглашению SLA, являются предпочтительными и будут часто сильно изменяться для разных отраслей промышленности и для разных компаний. Таблицы хранения представляют базовые данные, которые могут быть использованы первичным поставщиком услуг по соглашению SLA при управлении конкретными деловыми записями. Таким образом, данные конфигурации могут быть рассмотрены как исходная библиотека, с помощью которой первичный поставщик услуг по соглашению SLA определяет потенциальные значения данных, которые могут встретиться, с точки зрения типов предоставляемых услуг и временных рамок для ответов по соглашению SLA. Другие информационные группы, определенные как источники для логистической управляющей информации, представляют собой исходную библиотеку должностных инструкций по соглашению SLA, библиотеку профилей квалификации для предоставления услуг по соглашению SLA и матрицу соответствия подробных сведений по предоставлению услуг по соглашению SLA и профилей квалификации для предоставления услуг по соглашению SLA.
Информация (то есть исходная библиотека должностных инструкций для предоставления услуг по соглашению SLA, библиотека профилей квалификации для предоставления услуг по соглашению SLA и матрица соответствия подробных сведений по предоставлению услуг по соглашению SLA и профилей квалификации для предоставления услуг по соглашению SLA) обычно включает в себя подробные сведения, относящиеся к деловым или техническим способностям, применимым к предоставлению услуг, обеспечиваемому посредством ресурса первичного поставщика услуг по соглашению SLA коллективным клиентам соглашения SLA. В то время как элементы логистической управляющей информации, обсуждаемые выше, имеют дело с тем, как ведется бизнес, эти управляющие данные определяют, каково поле деятельности по предоставлению услуг. Иллюстративные таблицы базы данных, используемые для хранения информации о профиле квалификаций ресурса для предоставления услуг по соглашению SLA, включают в себя таблицы 23-26. Эти таблицы хранят идентифицирующую информацию конкретных профилей квалификации/атрибутов ресурсов для предоставления услуг по соглашению SLA, созданных первичным поставщиком услуг по соглашению SLA, и подробные сведения, применимые к профилю.
Таблица 26 сопоставляет основные записи любых применимых материалов с профилем ресурса для предоставления услуг, как считается необходимым. Типичный рассматриваемый случай представляет собой производителя генераторов, работающих на газе. В таком случае конкретный профиль предоставления услуг по соглашению SLA может быть создан для техника по ремонту или установке. Кроме того, производитель может хотеть назначить только заданные модели элементов генератора, которые будут связаны с профилем предоставления услуг по соглашению SLA и, следуя на шаг дальше, связать заданные части элементов, для которых профиль предоставления услуг по соглашению SLA должен иметь техническую квалификацию в обслуживании.
Как можно видеть по таблицам 23-25, большинство элементов данных, содержащихся в этих таблицах, являются целыми числами, а не текстовыми полями, поскольку система 100 является четко определенной с помощью библиотеки иерархических данных, служащей источником для таблиц профилей квалификации/атрибутов ресурсов для предоставления услуг по соглашению SLA. Данные исходной библиотеки содержатся в таблицах 14-22. Таблицы 14-22 содержат исходные данные профилей набора квалификаций, в то время как таблицы 23-25 содержат информацию, относящуюся к конкретному сконфигурированному и сохраненному профилю ресурса предоставления услуг по соглашению SLA. Хотя это явно не изображено, исходные данные, связанные с профилированием набора квалификаций, могут быть введены в среду данных, чтобы удовлетворять потребностям первичного поставщика услуг по соглашению SLA.
Функция основных данных, проиллюстрированная выше в общем виде на этапах 202-204, представляет собой основополагающий краеугольный камень, от которого управляют всеми действиями по предоставлению услуг по соглашению SLA. В вышеупомянутом комментарии первичный поставщик услуг по соглашению SLA определяет, например, для чего он присутствует в бизнесе, как он ведет бизнес, типы деловых/технических ресурсов, которые он использует для предоставления услуг клиентам, и где он обычно ведет бизнес. Фиг.4-9 и таблицы 1-36 предоставляют дополнительную информацию относительно функции основных данных.
Фиг.4 является блок-схемой последовательности операций, которая иллюстрирует высокоуровневую функциональность функции основных данных клиента соглашения SLA. Создание типа записи данных изображается на фиг.4 как линейный процесс. Изображенный процесс не обязательно является требованием или ограничением, а изображен как таковой только в целях общего понимания. Специалист в области техники поймет, что некоторые типы записей данных логически зависят от предварительных требований к записи основных данных. Например, было бы невозможно загрузить информацию о пользователе клиента соглашения SLA, если бы не было записи производственного предприятия клиента соглашения SLA, которая будет связана с ней.
На фиг.4 поток процесса 400 начинается на этапе 402. На этапе 402 создается запись клиента соглашения SLA либо вручную, либо через передачу данных. На этапе 404 загружаются деловые данные клиента соглашения SLA либо вручную, либо через передачу данных. На этапе 406 загружаются данные о пользователе клиента соглашения SLA либо вручную, либо через передачу данных. На этапе 408 загружается местоположение клиента соглашения SLA либо вручную, либо через передачу данных. На этапе 410 загружается договор клиента соглашения SLA. На этапе 412 создается запись (записи) предоставления услуг клиенту соглашения SLA. На этапе 414 создается запись (записи) для применяемых материалов для предоставления услуг клиенту соглашения SLA. На этапе 416 создается запись (записи) заказа на приобретение клиента соглашения SLA. На этапе 418 записи предоставления услуг клиенту соглашения SLA связываются с заказом на приобретение для создания отдельных позиций заказа на приобретение.
Фиг.5 является блок-схемой последовательности операций, которая иллюстрирует процесс для создания и сохранения в библиотеке профиля работника по предоставлению услуг по соглашению SLA. В общих чертах этот профиль представляет собой атрибуты квалификаций, необходимые для работника из трудовых ресурсов, для выполнения предоставления услуг, связанного с продуктом или системой первичного поставщика услуг по соглашению SLA. На фиг.5 процесс 500 начинается на этапе 502. На этапе 502 пользователь первичного поставщика услуг по соглашению SLA переходит с домашней страницы к управлению профилем квалификаций для предоставления услуг по соглашению SLA. На этапе 504 пользователь выбирает вариант создания нового профиля квалификаций для предоставления услуг. На этапе 506 пользователь выбирает сектор бизнеса из раскрывающегося списка. На этапе 508 пользователь выбирает арену бизнеса из ограниченного раскрывающегося списка. На этапе 510 пользователь выбирает семейство бизнеса из ограниченного раскрывающегося списка.
На этапе 512 пользователь выбирает общие функции из ограниченного раскрывающегося списка. На этапе 514 пользователь выбирает квалификации/атрибуты из ограниченного раскрывающегося меню. На этапе 516 пользователь добавляет пользовательские сертификаты, атрибуты и т.д., не содержащиеся в библиотеке исходных данных. На этапе 518 пользователь связывает профиль обслуживания с основной записью (записями) для материалов и определяет необходимую квалификацию. На этапе 520 пользователь добавляет название должности и дополнительное описание. На этапе 522 пользователь сохраняет созданную запись. На этапе 524 осуществляется определение, уникально ли название должности. Если это так, выполнение переходит на этап 526, на котором запись сохраняется в библиотеке профилей работников для предоставления услуг по соглашению SLA. Если на этапе 524 определено, что название должности не является уникальным, выполнение возвращается на этап 520. В оптимизированной среде первичный поставщик услуг по соглашению SLA создает полный список профилей обслуживания, которые удовлетворили бы всем обязательствам по предоставлению услуг.
Фиг.6 является блок-схемой последовательности операций, которая иллюстрирует процесс для создания и сохранения в библиотеке материалов для предоставления услуг по соглашению SLA. На фиг.6 процесс 600 начинается на этапе 602, в котором пользователь первичного поставщика услуг по соглашению SLA переходит в модуль материалов для предоставления услуг по соглашению SLA. На этапе 604 пользователь выбирает создание новой основной записи для материала. На этапе 606 пользователь определяет короткое название материала. На этапе 608 пользователь определяет описание материала. На этапе 610 пользователь определяет, является ли материал функцией или готовой продукцией. На этапе 612 пользователь определяет, хранится ли материал на складе. На этапе 614 пользователь определяет производителя материала. На этапе 616 пользователь определяет последнюю стоимость материала. На этапе 618 пользователь определяет дату для последней стоимости материала. На этапе 620 пользователь определяет количество имеющегося в наличии запаса материала. На этапе 622 пользователь определяет точку пополнения запаса для материала. На этапе 624 пользователь определяет количество пополнения запаса для материала. На этапе 626 пользователь сохраняет параметры.
На этапе 628 осуществляется определение, находится ли материал на складе. Если это так, то на этапе 628 выполнение переходит на этап 630. На этапе 630 пользователю предоставляется графический интерфейс пользователя (GUI), позволяющий выбор записей местоположения. На этапе 632 пользователь выбирает местоположение и определяет имеющееся в наличии количество. На этапе 634 пользователь сохраняет параметры. На этапе 636 сохраненные настройки сохраняются в библиотеке материалов для предоставления услуг по соглашению SLA. Если на этапе 628 не определено, что материал находится на складе, выполнение переходит на этап 636.
Различные аспекты должностной инструкции могут быть определены, например, не описательно, а в терминах базы данных. Может допускаться простое профилирование должностной инструкции, если оно является желательным режимом для первичного поставщика услуг по соглашению SLA. В таком случае инструмент профилирования квалификации можно опустить, допуская загрузку или создание вручную определенных названий должности и описаний, которые представляют квалификации, необходимые для предоставления услуг клиенту соглашения SLA. Фиг.5 и 6 являются иллюстративными для этих концепций.
Определение логистической управляющей информации сосредоточено на базовой компетентности первичного поставщика услуг по соглашению SLA; таким образом, вне контекста потребностей в предоставлении услуг конкретного клиента соглашения SLA логично определить и документировать, что может представлять собой объем обеспечиваемых услуг с точки зрения рабочей силы, гарантии, времени, оборудования и т.д., определение которых имеет место в пределах этой деятельности по управлению информацией.
Система 100 инициализирует цикл ссылок посредством предоставления возможности первичному поставщику услуг по соглашению SLA загрузить или ввести подробные сведения относительно договоров клиента соглашения SLA. Таблица 28 обеспечивает иллюстративное представление высокоуровневой информации, сохраняемой относительно конкретного договора. Большинство данных является основной деловой информацией; однако таблица 28 также хранит количество конкретных отдельных предоставляемых услуг, которые применимы к записи договора. Причина для указания количества состоит в том, чтобы удостовериться, что по мере выполнения процесса в обеспечивающей сети нет разрывов, и что все услуги по договору заняты и учтены. После ввода основных данных договора первичному поставщику услуг по соглашению SLA предоставляют возможность использовать конкретную запись договора по соглашению SLA как контрольную точку для создания записей с более точными сведениями по предоставлению услуг по соглашению SLA. См., например, таблицы 30-33.
Фиг.7 является блок-схемой последовательности операций, которая иллюстрирует процессы создания и сохранения, относящиеся к записям по предоставлению услуг по соглашению SLA. На фиг.7 поток процесса 700 начинается на этапе 702, в котором первичный поставщик услуг по соглашению SLA загружает поля данных договора и создает запись в таблице tblSLAclientContract (таблица 28). Процесс 700 может, например, являться линейным процессом, начинающимся со ввода основной информации договора, или пользователю может быть предоставлен графический интерфейс пользователя (GUI), дающий возможность пользователю выбрать конкретную запись договора по соглашению SLA из списка с несколькими записями договоров по соглашению SLA, отфильтрованного по клиенту соглашения SLA или другим переменным.
Этапы 704-708 относятся к созданию записи с подробными сведениями по предоставлению услуг по соглашению SLA. На этапе 704 системный графический интерфейс пользователя (GUI) запрашивает у пользователя создание связанных записей с подробными сведениями по предоставлению услуг по соглашению SLA. На этапе 706 пользователь активизирует управляющий элемент создания подробных сведений по предоставлению услуг по соглашению SLA. На этапе 708 система 100 заполняет новую запись данными по умолчанию из записей договора клиента соглашения SLA.
Этапы 710-712 относятся к выбору конкретного типа предоставления услуг, возможные значения которого, сохраненные, например, в таблице 3, уже были заданы через конфигурацию приложения. На этапе 710 система 100 запрашивает у пользователя выбор типа предоставления услуг. На этапе 712 пользователь выбирает тип предоставления услуг и сохраняет ввод.
Этапы 714-716 относятся к выбору конкретного типа работника для предоставления услуг, возможные значения которого, сохраненные, например, в таблице 4, уже были заданы через конфигурацию приложения. На этапе 714 система 100 запрашивает у пользователя выбор типа работника для предоставления услуг. На этапе 716 пользователь выбирает тип работника для предоставления услуг и сохраняет ввод.
Этапы 718-720 относятся к спецификации пользователя относительно оплачиваемой или неоплачиваемой природы деятельности по соглашению SLA. Неоплачиваемая деятельность будет иметь место, если по договору, например, поступила заявка на гарантийное обслуживание. На этапе 718 система 100 запрашивает у пользователя определение оплачиваемого или неоплачиваемого предоставления услуг. На этапе 720 пользователь определяет оплачиваемый или неоплачиваемый тип и сохраняет ввод. С этапа 720 выполнение переходит на этап 722.
Этапы 722-724 относятся к спецификации пользователя относительно применимости временного ограничения для этой записи, причем проиллюстрированный путь от этапа 724 подразумевает применимость. На этапе 722 система запрашивает у пользователя определение, требуется ли время ответа. На этапе 724 пользователь определяет, требуется ли время ответа и сохраняет ввод.
Этапы 726-728 относятся к выбору конкретного времени ответа по предоставлению услуг, возможные значения которого, сохраненные, например, в таблице 5, уже были заданы через конфигурацию приложения. Это время ответа обслуживания по соглашения SLA является промежутком времени от уведомления клиента соглашения SLA о проблеме до начала обслуживания поставщиком услуг соглашения SLA, как установлено между сторонами и обычно документировано в соответствующем договоре по соглашению SLA. На этапе 726 система 100 запрашивает у пользователя определение меры времени ответа, если это применимо. На этапе 728 пользователь определяет необходимое время ответа или меру и сохраняет ввод.
Этапы 730-732 относятся к вводу пользователем описательного комментария специфических подробных сведений, информации договора или общей информации по желанию. На этапе 730 система 100 запрашивает у пользователя заполнение подробного описания предоставления услуг. На этапе 732 пользователь заполняет подробные сведения и сохраняет ввод.
Этапы 734-736 относятся к спецификации/оценке пользователем первичной стоимости предоставления услуг по соглашению SLA. На этапе 734 система 100 запрашивает у пользователя предоставление стоимости предоставления услуг. На этапе 736 пользователь заполняет стоимость предоставления услуг и сохраняет ввод.
Этапы 738-740 относятся к спецификации/оценке пользователем количества случаев предоставления услуг по соглашению SLA, которые могут применяться. Базовое логистическое планирование обычно требует такое проектирование. Такая информация оказывает прямое влияние на последующий процесс запросов (RFx) предложений. Информация состоит из количества, через которое поставщик услуг планирует наличие ресурсов и привлекает процесс предложений, чтобы установить наилучшую договорную цену. На этапе 738 система 100 запрашивает у пользователя определение ожидаемой или запланированной частоты предоставления услуг. На этапе 740 пользователь заполняет оценку частоты предоставления и сохраняет ввод.
В процессе, изображенном на этапах 742-746, у пользователя запрашивают выбор конкретного профиля квалификаций для предоставления услуг по соглашению SLA для связывания с записью с подробными сведениями по предоставлению услуг по соглашению SLA. У пользователя есть вариант выбора либо профиля квалификаций для предоставления услуг по соглашению SLA, либо, как указано ранее, сохраненного названия должности, если первичный поставщик услуг по соглашению SLA решил использовать этот режим. Хотя процесс изображает выбор ранее сохраненной записи, система 100 может поддерживать различное создание либо описания должности, либо профиля квалификаций для предоставления услуг по соглашению SLA. Оптимальная практика предусматривает заранее созданные и сохраненные записи профилей ресурсов для предоставления услуг по соглашению SLA, являющиеся предпосылкой динамики бизнеса первичного поставщика услуг по соглашению SLA. Ранее сохраненные подробные сведения записи профиля ресурсов сохранены, например, в таблицах 23-25. На этапе 742 система 100 запрашивает у пользователя определение подходящего профиля квалификаций для предоставления услуг по соглашению SLA или названия должности. На этапе 744 пользователь выбирает профиль или название должности из раскрывающегося меню. На этапе 746 система 100 запрашивает у пользователя сохранение привязки подробных сведений по предоставлению услуг к профилю работника, и пользователь сохраняет привязку.
В процессе, изображенном в этапах 748-750, у пользователя запрашивают выбор и привязку подходящего оборудования/местоположений предоставления услуг клиенту соглашения SLA. На этапе 748 у пользователя запрашивают определение подходящих местоположений клиента сервиса соглашения SLA. На этапе 750 пользователь выбирает местоположения клиента соглашения SLA из раскрывающегося меню и сохраняет ввод.
Во время процесса, изображенного на этапах 752-760, у пользователя запрашивают выбор каких-либо взаимосвязей с материалами, которые могут существовать относительно записи с подробными сведениями по предоставлению услуг по соглашению SLA. Этап 752 обычно является простым запросом ответа "да/нет"; на этапе 752 выбор в иллюстративных целях представляет собой ответ "да". На этапе 752 система 100 запрашивает у пользователя определение требований каких-либо материалов для предоставления услуг по соглашению SLA. На этапе 754 пользователь выбирает материалы из раскрывающегося меню. Список материалов по умолчанию предоставляется на основе ранее установленных взаимосвязей, созданных между профилями квалификаций для предоставления услуг по соглашению SLA и основными записями материалов, сохраненных, например, в таблице 26. Такой список может быть предоставлен как оптимальный режим обработки деловой информации, но не должен служить ограничением, то есть у пользователя может быть доступ ко всему списку основных записей материалов, если это желательно.
Во время процесса, изображенного на этапах 756-758, у пользователя запрашивают установку параметров конфигурации, применимых к каким-либо выбранным основным записям материалов. Пользователь указывает, например, являются ли материалы оплачиваемыми/неоплачиваемыми, гарантийные товары, товары на складе, требования по складированию и т.д. Специалисты в области техники поймут, что атрибуты конфигурации, проиллюстрированные в таблице 31, не являются ограничением, и к приложению и базе данных могут быть добавлены дополнительные атрибуты. На этапе 756 у пользователя запрашивают конфигурирование требований к материалам для соглашения SLA, такие как требования складирования, назначение для гарантийного обслуживания и т.д. На этапе 758 пользователь конфигурирует записи материалов. На этапе 760 пользователь сохраняет параметры и привязки для материалов.
Во время процесса, изображенного на этапах 762-768, у пользователя запрашивают сохранение и наименование записи с подробными сведениями по предоставлению услуг по соглашению SLA. Хотя поток процесса явно не изображает эту функциональность, пользователь первичного поставщика услуг по соглашению SLA может сохранять запись во временном состоянии для ее завершения в другое время. В таком случае база данных должна поддерживать отслеживание через коды состояния завершенных или незавершенных и активных или неактивных записей. На этапе 762 система 100 запрашивает у пользователя сохранение записи с подробными сведениями по предоставлению услуг, и пользователь сохраняет запись. На этапе 764 система 100 запрашивает у пользователя определение имени записи с подробными сведениями по предоставлению услуг. На этапе 766 пользователь заполняет название подробных сведений по предоставлению услуг и сохраняет ввод. На этапе 768 запись с подробными сведениями по предоставлению услуг по соглашению SLA создается и сохраняется.
Обычно от первичного поставщика услуг по соглашению SLA не ожидают использования возможностей информационной поддержки для договора по соглашению SLA, если никогда не было потребностей, исходящих от клиента соглашения SLA. Как правило, соглашениями об уровне услуг управляют через договоры. Имеется понятная деловая потребность связать по ссылке действия по предоставлению услуг и исполняемые договоры, поскольку подробные сведения договора по соглашению SLA обычно присутствуют в отдельном приложении управления договором с ограниченными возможностями функционального взаимодействия с приложениями снабжения предприятия, управления проектами или обработки финансовых данных или без таких возможностей. Во многих случаях подробные сведения договора присутствуют только на бумаге. Таким образом, ввод основных подробных сведений договора в приложение, которое будет фактически управлять конкретными действиями по соглашению SLA, является усовершенствованием по сравнению со стандартными деловыми процедурами. Ввод этих основных подробных сведений договора в приложение управления дает возможность действиям основного направления по соглашению SLA и обработки административно-управленческой информации происходить таким образом, посредством которого поток деловой активности придерживается первоначального договора по соглашению SLA.
Фиг.8 является блок-схемой, которая иллюстрирует процессы создания и сохранения, относящиеся к заказам на приобретение от клиентов соглашения SLA. Информация о заказе на приобретение, рассматриваемая в отношении фиг.8, отличается от выполняемого сторонним исполнителем процесса снабжения по соглашению SLA. Многие предприятия бизнеса предпочитают проводить финансовые операции при содействии управляемой финансовой системы. К сожалению, вследствие сложной природы работы по предоставлению услуг по соглашению SLA, большая часть подробных сведений управления не может быть перенесена/передана из договора по соглашению SLA в финансовую систему, поскольку большинство финансовых систем/систем снабжения сконфигурированы в упрощенном режиме "описание-количество-стоимость". Это обычно приводит к сценарию, в котором реальные подробные сведения присутствуют в договоре, а финансовая система в действительности содержит запись полномочий финансовых операций.
Различные варианты воплощения разрешают извлечение этих подробных сведений договора по соглашению SLA для использования во многих целях, одна из которых состоит в том, чтобы установить оптимальный процесс заказа на приобретение. В конечном счете, многие из действий по предоставлению услуг по соглашению SLA приведут к операциям по оплате. Таким образом, имеет логический смысл ожидать эту деловую потребность и устанавливать взаимосвязь между конкретными записями с подробными сведениями по предоставлению услуг по соглашению SLA и заказами на приобретение, созданными для клиента соглашения SLA и первичного поставщика услуг по соглашению SLA, чтобы провести финансовые операции.
На фиг.8 поток процесса 800 начинается на этапе 802, на котором первичный поставщик услуг по соглашению SLA совершает конфигурацию записи с подробными сведениями по предоставлению услуг. Этап 802 представляет предварительно требуемую деятельность, которая была описана в предшествующем описании информации о подробных сведениях по предоставлению услуг по соглашению SLA. От этапа 802 выполнение переходит на этап 804.
Этапы 804-808 иллюстрируют процесс, посредством которого пользователь первичного поставщика услуг по соглашению SLA получает доступ к записям с подробными сведениями по предоставлению услуг по соглашению SLA, которые не связаны с соответствующим заказом на приобретение клиента соглашения SLA, и выбирает конкретные записи для такого присоединения по желанию. Записи с подробными сведениями по предоставлению услуг по соглашению SLA идентифицированы для конкретного клиента соглашения SLA, у которого нет записей авторизации платежей для финансовой системы. В этом процессе пользователь может использовать фильтры базы данных, такие как, например, название клиента соглашения SLA, дату, пользователя первичного клиента соглашения SLA, чтобы сузить выходной набор записей. Система 100 запрашивает у пользователя первичного поставщика услуг по соглашению SLA установку механизма обработки финансовых операций. На этапе 804 система 100 запрашивает у пользователя первичного поставщика услуг по соглашению SLA привязку записей с подробными сведениями по предоставлению услуг к заказу на приобретение. На этапе 806 пользователь обращается к подробным сведениям по предоставлению услуг, не связанным с отчетом о заказе на приобретение. На этапе 808 пользователь выбирает ограниченные записи с подробными сведениями по предоставлению услуг через графический интерфейс пользователя (GUI).
На этапе 810 пользователь активизирует элемент управления создания заказа на приобретение клиента соглашения SLA. На этапе 812 система 100 формирует новый заказ на приобретение в ждущем статусе ожидания. На этапе 814 позиции заказа на приобретение наследуют подробные сведения из записей с подробными сведениями по предоставлению услуг по соглашению SLA. Этапы 810-814 не подразумевают, что только новая запись заказа на приобретение может быть создана во время выполнения потока 800. Хотя это явно не изображено, может быть отображена и выбрана существующая запись заказа на приобретение клиента соглашения SLA, что будет иметь место, когда предпочтительный режим клиента соглашения SLA предусматривает использование единого заказа на приобретение. Чтобы не загромождать существенные признаки процесса, изображенного посредством этапов 810-814, процесс представлен созданием новой записи заказа на приобретение. В процессе, изображенном на этапах 810-814, некоторые конфигурируемые элементы записи с подробными сведениями по предоставлению услуг по соглашению SLA обычно автоматически заполняют позиции заказа. Точно так же некоторые подробные сведения договора соглашения SLA при конфигурировании заполняют заголовок заказа на приобретение.
Этапы 816-826 представляют процессы, посредством которых пользователь первичного поставщика услуг по соглашению SLA заполняет традиционную финансовую информацию, применимую к заказу на приобретение. Изображенные иллюстративные информационные элементы включают в себя максимальные расходы на заказ на приобретение, нормы оплаты труда по обслуживанию и нормы расхода материалов. На этапе 816 система 100 запрашивает у пользователя определение максимальных расходов на заказ на приобретение. На этапе 818 пользователь определяет максимальные расходы и сохраняет ввод. На этапе 820 система 100 запрашивает у пользователя определение норм оплаты труда по обслуживанию. На этапе 822 пользователь определяет нормы оплаты труда и сохраняет ввод. На этапе 824 система 100 запрашивает у пользователя определение норм расхода материалов. На этапе 826 пользователь определяет нормы расхода материалов и сохраняет ввод.
Этапы 828-830 являются основными этапами в сохранении заказа на приобретение. На данной стадии в процессе 800 заказ на приобретение еще не является активным. На этапе 828 система 100 запрашивает у пользователя сохранение заполненного заказа на приобретение. На этапе 830 пользователь сохраняет заполненный заказ на приобретение.
Этапы 832-840 представляют собой процессы обработки заказа на приобретение клиента соглашения SLA и одобрения. На этапе 832 система 100 перенаправляет заполненный заказ на приобретение сконфигурированному пользователю клиента соглашения SLA как инициированный, например, посредством кода состояния, соединенного с записью на этапе 830. Выпускаются уведомления, например, через электронную почту и обновление системной панели управления. На этапе 834 пользователь клиента соглашения SLA обращается к ожидающему заказу на приобретение через графический интерфейс пользователя (GUI). На этапе 836 пользователь клиента соглашения SLA проверяет правильность данных заказа на приобретение. На этапе 838 система 100 запрашивает у клиента соглашения SLA одобрение заказа на приобретение и назначает порядковый номер заказа на приобретение клиента соглашения SLA. На этапе 840 пользователь клиента соглашения SLA одобряет заказ на приобретение и назначает порядковый номер заказа на приобретение клиента соглашения SLA. Этапы 836-840 явно не изображают сценарий, посредством которого пользователь клиента соглашения SLA не подтверждает правильность данных заказа на приобретение. Система 100, однако, обеспечивает функциональные возможности пересылки назад и вперед, когда необходимы исправления или элементы данных являются предметом спора. Имеется процесс совместной проверки правильности и одобрения, содержащийся в системе 100, который облегчает и гарантирует правильные данные во время последующих действий по обработке данных.
Этапы 842-848 представляют собой действия, предпринимаемые пользователем первичного поставщика услуг по соглашению SLA, для завершения процесса заказа на приобретение клиента соглашения SLA и предоставления возможности активизировать заказ на приобретение в системе 100. На этапе 842 система 100 перенаправляет одобренный заказ на приобретение клиента соглашения SLA назад первичному поставщику услуг по соглашению SLA. Выпускаются уведомления, например, через электронную почту и обновление системной панели управления. На этапе 844 пользователь первичного поставщика услуг по соглашению SLA обращается к одобренному заказу на приобретение через графический интерфейс пользователя (GUI). На этапе 846 система 100 запрашивает у пользователя первичного поставщика услуг по соглашению SLA активизацию заказа на приобретение. На этапе 848 пользователь первичного поставщика услуг по соглашению SLA активизирует заказ на приобретение.
Основные данные, поддерживающие модель базы данных, представлены на фиг.9. Специалисты в области техники поймут, что эта модель данных поддержки и модуль прикладных программ по существу служат в качестве инфраструктуры для выполнения предоставления услуг по соглашению SLA. Интегрированная модель данных обобщает первичные и основные деловые информационные аспекты, требуемые для ведения бизнеса оптимизированным образом, отображая внутреннюю реляционную природу деловой информации. Как указано ранее, эти по своей природе связанные аспекты деловой информации традиционно присутствуют в несопоставимых системах обработки данных, которые традиционно не взаимодействуют друг с другом. Благодаря этому модулю прикладных программ и поддерживающей схеме базы данных первичные поставщики услуг по соглашению SLA теперь могут определять и хранить в пределах одной системы обработки данных свои требования по предоставлению услуг по соглашению SLA таким способом, который подлинно отражает динамику бизнеса, который должен учитывать, например: договоры, сотрудников для контакта, физические местоположения, требуемые атрибуты работников по предоставлению услуг, логистические параметры, штрафы за невыполнение и авторизацию финансовой обработки.
Функция снабжения имеет дело специально с действиями по подбору источников снабжения, предложению цены и формированию заказов на приобретение, предпринимаемыми первичным поставщиком услуг по соглашению SLA и вторичными поставщиками услуг по соглашению SLA. Эти действия обычно предусматривают: 1) предоставление первичным поставщикам услуг по соглашению SLA возможности собирать и хранить деловую информацию, применимую к вторичным поставщикам услуг по соглашению SLA; 2) предоставление первичным поставщикам услуг по соглашению SLA возможности классифицировать вторичных поставщиков услуг по соглашению SLA в терминах обеспечения квалификации по соглашению SLA и возможностей географического охвата; 3) предоставление первичным поставщикам услуг по соглашению SLA возможности систематически идентифицировать и количественно определять требования по охвату для клиента соглашения SLA, как подробно описано в функции основных данных; 4) предоставление первичным поставщикам услуг по соглашению SLA возможности формировать систематические запросы (RFx) на предложения из записей охвата клиента соглашения SLA; 5) предоставление первичным поставщикам услуг по соглашению SLA возможности систематически формировать списки предложений вторичных поставщиков услуг по соглашению SLA для созданных запросов (RFx) на предложения, которые должны быть отправлены для обработки ответа на предложения; 6) предоставление вторичным поставщикам услуг по соглашению SLA возможности систематически формировать ответы на запросы (RFx) на предложения и представлять соответствующие трудовые ресурсы, связанные с ответами, при необходимости; 7) предоставление первичным поставщикам услуг по соглашению SLA возможности делать систематический обзор представленных ответов на запросы (RFx) на предложения; и 8) предоставление первичным поставщикам услуг по соглашению SLA возможности систематически принимать/присуждать ответы на запросы (RFx) на предложения и создавать заказы на приобретение для вторичных поставщиков услуг по соглашению SLA со ссылкой на подробные сведения ответов на запросы (RFx) на предложения. Таблицы 37-52 и фиг.10-13, в частности, относятся к этим действиям. Логическая систематическая методология, описанная выше относительно функции основных данных, дает возможность первичному поставщику услуг по соглашению SLA определить свои потенциальные услуги по соглашению SLA в терминах дискретных требований квалификации персонала для предоставления услуг, пригодности материалов/частей, и физические местоположения/география служат в качестве базовой информационной платформы, посредством которой вторичные поставщики услуг по соглашению SLA классифицированы и подобраны в качестве источников...
Фиг.10 является блок-схемой, которая иллюстрирует процесс подготовки ввода в систему вторичного поставщика услуг по соглашению SLA. На фиг.10 поток 1000 процесса включает в себя этапы 1005-1080. Этапы 1005-1025 представляют собой базовые этапы, на которых вторичный поставщик услуг по соглашению SLA одобряется и заносится в систему 100. Поток 1000 процесса начинается в этапе 1005, на котором первичный поставщик услуг по соглашению SLA конфигурирует поля деловой информации и какие-либо подходящие данные специфицирующих параметров, относящихся ко вторичному поставщику услуг по соглашению SLA. На этапе 1010 после завершения конфигурации базовой деловой информации для спецификации вторичного поставщика услуг по соглашению SLA, потенциальным вторичным поставщикам услуг по соглашению SLA от первичного поставщика услуг по соглашению SLA выдаются мандаты временного доступа к системе. Эти мандаты могут быть переданы в нескольких режимах, например, по телефону, с помощью зашифрованного сообщения.
Мандаты дают возможность пользователю вторичного поставщика услуг по соглашению SLA получить доступ к системе 100. Пользователю вторичного поставщика услуг по соглашению SLA предоставляют графический интерфейс пользователя (GUI), аналогичный показанному на фиг.3, с помощью которого используется методика навигации для получения доступа к формам ввода первичной деловой информации. На этапе 1015 вторичный поставщик услуг по соглашению SLA завершает ввод общей деловой информации и представляет ее на рассмотрение первичному поставщику услуг по соглашению SLA.
Этапы 1020-1025 изображают рассмотрение первичным поставщиком услуг по соглашению SLA и размещение информации спецификации, представленной вторичным поставщиком услуг по соглашению SLA. Этот рабочий поток проиллюстрирован только относительно положительного результата, посредством которого вторичный поставщик услуг по соглашению SLA квалифицируется/одобряется для ведения бизнеса. На этапе 1020 первичный поставщик услуг по соглашению SLA одобряет вторичного поставщика услуг по соглашению SLA, если первичный поставщик услуг по соглашению SLA считает вторичного поставщика услуг по соглашению SLA квалифицированным. На этапе 1025 вторичный поставщик услуг по соглашению SLA уведомляется относительно одобрения, ему выдаются мандаты для регулярного входа в систему, и ему поручают заполнить матрицу профиля предоставления услуг. Во время этапов 1005-1025 первичный поставщик услуг по соглашению SLA конфигурирует информационные функции, к которым он хочет дать доступ, а также идентифицирующие для системы 100 любые предопределенные необходимые значения, которые служат параметрами квалификации. Иллюстративные базовые элементы деловой информации содержатся в таблицах 40-41. Первичный поставщик услуг по соглашению SLA фактически не имеет никаких ограничений конфигурации относительно параметров квалификации, которые он желает сделать функциональным в системе 100.
Этапы 1030-1055 иллюстрируют основные этапы, посредством которых вторичный поставщик услуг по соглашению SLA документирует свои возможности предоставления услуг в контексте поля деятельности и географии. Вторичному поставщику услуг по соглашению SLA предоставляют графический интерфейс пользователя (GUI), который дает ему возможность доступа к инструментальному средству профилирования бизнеса. Инструментальное средство профилирования бизнеса запрашивает у пользователя навигацию на инструментальное средство детализации иерархических отношений "сектор-арена-семейство". На этапе 1030 пользователь вторичного поставщика услуг по соглашению SLA обращается к функции профилирования предоставления услуг. На этапе 1035 в соответствии с предварительно сконфигурированными правилами вторичный поставщик услуг по соглашению SLA просматривает полный список семейств бизнеса по предоставлению услуг или его ограниченное подмножество первичного поставщика услуг по соглашению SLA. Используя это инструментальное средство, вторичный поставщик услуг по соглашению SLA может определить, какие конкретные функциональные/технические специализации представляют его основные компетенции. На этапе 1040 вторичный поставщик услуг по соглашению SLA выбирает записи семейств бизнеса, применимых к возможностям поставки ресурсов вторичного поставщика услуг по соглашению SLA.
После выбора семейств бизнеса вторичный поставщик услуг по соглашению SLA может затем использовать инструментальное средство географической спецификации (например, "страна-область-округ-город") и привязать территориальные области охвата для любых выбранных семейств бизнеса. На этапе 1050 вторичный поставщик услуг по соглашению SLA использует пользовательский интерфейс географической реляционной базы данных для определения территории обслуживания. Спецификация соответственно национальных, регионального охвата или охвата в пределах округа или населенного пункта. В типичном варианте воплощения пользовательский интерфейс поддерживает составное или индивидуальное сопоставление семейства бизнеса и географической территории. После сохранения желаемых выбранных вариантов, например, в таблицах 42-46, вторичный поставщик услуг по соглашению SLA может представить выбранные варианты обратно первичному поставщику услуг по соглашению SLA для рассмотрения и размещения. На этапе 1055 вторичный поставщик услуг по соглашению SLA сохраняет и представляет матрицу соответствия семейств бизнеса и охватов географических территорий.
Если желательно, первичный поставщик услуг по соглашению SLA может ограничить спецификацию матрицы предоставления услуг для вторичных поставщиков услуг по соглашению SLA до только тех профилей квалификации для предоставления услуг и географических спецификаций, которые определены в функции основных данных. В иллюстративных целях эти ограничения подробно не рассматриваются; специалисты в области техники поймут, что использование таких ограничений могут в общем случае упростить встроенную обработку для вторичного поставщика услуг по соглашению SLA, но необычно не будет считаться оптимальным режимом работы, при условии, что отображение макроданных возможностей по предоставлению услуг у вторичного поставщика услуг по соглашению SLA является оптимальным представлением, когда принимается во внимание изменение требований к бизнесу.
Этапы 1060-1080 изображают завершение потока 1000 процесса. Как и ранее, подробно рассматривается только положительное размещение представления вторичного поставщика услуг по соглашению SLA. Общим результатом потока 1000 процесса является сопоставление вторичных поставщиков услуг по соглашению SLA как с семейством бизнеса, так и с географической областью территориального охвата. На этапе 1060 первичный поставщик услуг по соглашению SLA делает обзор представленной матрицы соответствия семейств бизнеса и географических охватов территории, созданной вторичным поставщиком услуг по соглашению SLA. В этапе 1065 первичный поставщик услуг по соглашению SLA одобряет матрицу соответствия семейств бизнеса и географических охватов территории. На этапе 1070 статус матрицы соответствия семейств бизнеса и географических охватов территории вторичного поставщика услуг по соглашению SLA изменяется на одобренный и активный. На этапе 1075 вторичный поставщик услуг по соглашению SLA уведомляется относительно одобрения представления и изменения статуса матрицы, например, через интерактивные уведомления и по электронной почте. На этапе 1080 вторичному поставщику услуг по соглашению SLA предоставляется возможность принимать систематические запросы (RFx) на предложения на основе критериев семейства бизнеса и географической территории.
В конце потока 1000 процесса первичный поставщик услуг по соглашению SLA собрал и сохранил информацию относительно потенциальных потребностей по предоставлению услуг клиентов соглашения SLA, а также потенциальных возможностей охвата обслуживания вторичных поставщиков услуг по соглашению SLA. Следующие этапы в полном процессе 200 относятся к идентификации требований запросов (RFx) предложения, формированию запросов (RFx) предложения и ходатайству с запросами (RFx) на предложения.
Фиг.11 является типовым выходным отчетом, детализирующим записи с подробными сведениями по предоставлению услуг по соглашению SLA, не связанные по меньшей мере с одним заказом на приобретение вторичного поставщика услуг по соглашению SLA. Выходной системный отчет 1100 для первичного поставщика услуг по соглашению SLA детализирует все активные записи с подробными сведениями по предоставлению услуг клиенту соглашения SLA, которые не присоединены ни к активному запросу (RFx) на предложения, ни к активному заказу на приобретение вторичного поставщика услуг по соглашению SLA.
Используемая стратегия состоит в том, чтобы документировать потенциальные требования клиента соглашения SLA в формализованной методологии базы данных, которая учитывает каждое требование, связывает каждое требование с конкретной записью, устанавливает соответствие между каждой записью и профилем квалификаций для предоставления услуг по соглашению SLA и назначает точки географического охвата, присоединенные к требованию. Результатом этой методологии является выходной отчет 1100, готовящий почву для создания запросов (RFx) на предложения, которые будут выпущены для вторичных поставщиков услуг по соглашению SLA с целью получения котировок.
Элементы 1115, 1120 и 1125 управления представляют собой элементы управления различного представления для пользователя первичного поставщика услуг по соглашению SLA, которые дают возможность пользователю группировать и обозревать наборы записей в более широких географических сегментах. Элементы 1115, 1120 и 1125 управления являются обычными персональными настройками для удобства и деловой практики.
Элемент 1105 управления предоставляет пользователю ссылку на подробное описание должностных инструкций по соглашению SLA. Этот путь выполнен с возможностью обеспечить расширенное представление. Когда это поле не используется первичным поставщиком услуг по соглашению SLA, ссылка является неактивной или затененной, тем самым препятствуя тому, чтобы пользователь вдавался в подробности.
Элемент 1110 управления предоставляет пользователю ссылку на соответствующий подробный профиль квалификаций для предоставления услуг по соглашению SLA. Этот путь выполнен с возможностью обеспечить расширенное представление. Кроме того, когда это поле не используется первичным поставщиком услуг по соглашению SLA, ссылка является неактивной или затененной, тем самым препятствуя тому, чтобы пользователь вдавался в подробности.
Элементы 1101, 1130 и 1135 управления являются соответственно первичными элементами управления, которые используются для выбора конкретной записи или группы записей для включения в новый запрос (RFx) на предложения и определения, должны ли выбранные записи быть сгруппированы в один запрос (RFx) на предложения или каждая выбранная запись должна быть связана с уникальным запросом (RFx) на предложения. Элемент 1135 управления является неактивным до тех пор, пока не выбраны по меньшей мере две записи.
После выбора желаемых записей через элемент 1101 управления и определения предпочтения для включения либо нескольких, либо одного запроса (RFx) (элемент 1130 или 1135 управления) пользователь активизирует элемент управления создания запроса (RFx) (элемент 1140 управления), чтобы начать процесс разработки запроса (RFx). Цель бизнеса состоит в том, чтобы не иметь записей, появляющихся в отчете о несвязанных записях с подробными сведениями по предоставлению услуг по соглашению SLA, поскольку это означает, что не имеется охвата предоставления услуг сторонних исполнителей или по субподрядному договору для соответствующего клиента (клиентов) соглашения SLA.
Фиг.12A-12B являются блок-схемами последовательности операций, которые иллюстрируют процессы высокого уровня, применимые к снабжению, выполняемому сторонними вторичными поставщиками услуг по соглашения SLA. На фиг.12A проиллюстрирован поток 1200 процесса, направленный на разработку запросов (RFx) на предложения и выбор и ходатайство запросов (RFx) на предложения вторичным поставщиком услуг по соглашению SLA. Поток 1200 процесса начинается на этапе 1202. На этапе 1202 первичный поставщик услуг по соглашению SLA выполняет обеспечиваемый системой отчет о несвязанных записях с подробными сведениями по предоставлению услуг клиенту соглашения SLA. На этапе 1204 система 100 предоставляет пользователю первичного поставщика услуг по соглашению SLA функцию для формирования запросов (RFx) на предложения из выбранных записей отчета. На этапе 1206 система 100 создает записи запросов (RFx) на предложения, сконфигурированные на этапе 1204. На этапе 1208 запускается сеанс создания запросов (RFx) на предложения для пользователя первичного поставщика услуг по соглашению SLA. Специалисты в области техники поймут, что этап 1208 может быть запущен независимо из меню графического интерфейса пользователя (GUI): это означает, что пользователю первичного поставщика услуг по соглашению SLA не обязательно требуется создавать запрос (RFx) на предложения, выполняя вывод отчета, описанный ранее на этапах 1202-1206. В таком случае система 100 может предоставить пользователю все записи, которые были намечены для включения запросов (RFx), но по каким-либо причинам еще не завершенных. Однако в демонстрационных целях поток 1200 процесса изображает процесс, посредством которого сессия создания запросов (RFx) выполняется непосредственно действиями пользователя, выполняемыми вместе с типовым выходным отчетом, показанным на фиг.11.
Как проиллюстрировано, пользователь первичного поставщика услуг по соглашению SLA запускает сеанс создания запросов (RFx) на предложения на этапе 1208, и ему предоставляется набор доступных записей. На этапе 1210 пользователь выбирает конкретный запрос (RFx) на предложения, связанный желаемыми записями с подробными сведениями по предоставлению услуг. Несколько записей с подробными сведениями по предоставлению услуг могут быть объединены в один запрос (RFx).
На этапе 1212 предварительно сконфигурированные элементы базы данных, применимые к записям с подробными сведениями по предоставлению услуг, используются для заполнения элементов запроса (RFx) на предложения. Запросы (RFx) на предложения наследуют подробные сведения из набора записей по предоставлению услуг по соглашению SLA, включающие в себя, например, профиль квалификаций для предоставления услуг по соглашению SLA, подробные сведения местоположения обслуживания, требования по предоставлению услуг по соглашению SLA и ожидаемую частоту обслуживания. Этап 1212 обычно представляет собой немного больше, чем представленная форма графического интерфейса пользователя (GUI), дающая возможность пользователю получить доступ к индивидуальным записям через стандартные методики навигации. Специалисты в области техники поймут легкость в управлении, которую этот процесс предоставляет пользователю, а также тот факт, что ошибки ввода данных фактически устраняются. Подходящие подробные сведения, применимые к физическому предоставлению услуг и его логистике, собираются непосредственно из записей с подробными сведениями по предоставлению услуг по соглашению SLA, которые непосредственно связаны с записями договора клиента соглашения SLA.
Как только установлен основной набор записей на запрос (RFx), пользователь первичного поставщика услуг по соглашению SLA затем имеет доступ для редактирования/конфигурирования записей на этапе 1215. На этапе 1215 пользователь первичного поставщика услуг по соглашению SLA конфигурирует, например, варианты типа работников, условия штрафов по соглашению SLA и максимальные нормы.
Хотя пользователь может решить не предпринимать действий, пользователю могут быть предоставлены варианты, с тем чтобы можно было улучшить деловую деятельность. Элементы данных, такие как типы норм оплаты труда, максимальные нормы, условия штрафов по соглашению SLA и сроки ответов по предоставлению услуг, могут быть сконфигурированы, например, для обеспечения того, чтобы были установлены цели доходности и качества предоставления услуг во время процесса предложения. Примером являются расценки. С точки зрения первичного поставщика услуг по соглашению SLA было бы оптимально превзойти расценки, назначаемые вторичными поставщиками услуг по соглашению SLA, на уровне, который равен или меньше расценок, которые будут в конечном счете оплачены соответствующим клиентом соглашения SLA. Другим примером являются сроки ответов по предоставлению услуг. Опять же, с точки зрения производительности является оптимальным, если сроки ответа по предоставлению услуг сделаны короче, чем сроки по договору, которые применимы к первичному поставщику услуг по соглашению SLA. Пользовательский интерфейс с возможностями редактирования позволяет первичному поставщику услуг по соглашению SLA защитить свои интересы в систематической инфраструктуре.
Этап 1218 является процессом сохранения после завершения конфигураций этапа 1215. На этом этапе в системе 100 могут быть предусмотрены средства поддержки принятия решений, которые проверяют и подтверждают правильность каких-либо конфигураций пользователя, которые могли привести к потенциальным проблемам для первичного поставщика услуг по соглашению SLA. Проверки, такие как анализ доходности или качества, могут использоваться для указания пользователю, что параметры, применимые к заданным элементам предложения, могут привести к увеличенным рискам деловой деятельности.
На этот момент первичные подробные сведения, которые необходимы для отправки запроса (RFx) на предложения вторичным поставщикам услуг по соглашению SLA, заполнены; однако остается заполнить различные административные подробные сведения. Как правило, запрос (RFx) на предложения будет содержать конкретные элементы, такие как, например, раздел заголовка предложения, раздел подробных сведений предложения и раздел ответа на запрос о предложении. Запросы (RFx) на предложения обычно сопровождаются определенным набором соглашений поставщика, которые выполняются во время обработки ответа на запрос о предложении. Кроме того, природа запросов (RFx) на предложения такова, что значительная часть информации относительно наиболее выпускаемых предложений является избыточной и стандартной по формату и содержанию во всем деловом предприятии. Таким образом, инструментальное средство шаблона предложения используется для разрешения вопросов, относящихся к содержанию и форматированию запроса (RFx) на предложения.
Относительно шаблонов запроса (RFx) на предложения конкретные таблицы базы данных хранят заданные по умолчанию информационные элементы запроса (RFx) на предложения, такие как, например, вопросы и ответы анкет. Первичный поставщик услуг по соглашению SLA может конфигурировать стандартное содержание по умолчанию, применимое к заданным по умолчанию информационным элементам запроса (RFx) на предложения. Таким образом, информационные элементы могут быть предопределены и не требовать редактирования пользователем. Кроме того, система 100 может хранить конкретные конфигурируемые информационные элементы, это означает, что пользователь может создать элемент предложения, назначить элемент ответом, вопросом и т.д., затем назначить, требует ли информационный элемент ответа поставщика, и назначить, является ли ответ ограниченным конкретным типом данных, таким как, например, число, текст, дата или валюта.
В различных вариантах воплощения инфраструктура предоставления услуг включает в себя позиции запроса (RFx) на предложения. Могут быть сделаны привязки позиций запроса (RFx) на предложения к логическим заданным по умолчанию категориям и разделам запроса (RFx) на предложения. Каждой позиции предложения может быть назначена логическая группа или категория, и одним уровнем выше каждая категория может быть логически сгруппирована в раздел. Таким образом, допускается группирование содержания запроса (RFx) на предложения.
Над группированием содержания предложений находится более сложный уровень шаблона запроса (RFx) на предложения, который дает возможность первичному поставщику услуг по соглашению SLA установить порядок отображения в интерфейсе пользователя (UI) разделов, категорий в пределах разделов и позиций запроса (RFx) на предложения в пределах категорий. Таким образом, различные позиции запроса (RFx) могут быть созданы и сохранены в структурированном формате содержания и размещения. Таким образом, шаблоны запроса (RFx) на предложения представляют собой механизм управления деловым информационным содержанием, который при объединении с данными подробных сведений запросов (RFx) формирует основу для быстрого и детализированного формирования запросов (RFx) на предложения.
Шаблоны запроса (RFx) на предложения хранятся в системе 100, и на этапе 1220 у пользователя первичного поставщика услуг по соглашению SLA запрашивают выбор предварительно сконфигурированного шаблона запроса (RFx) на предложения. У пользователя первичного поставщика услуг по соглашению SLA запрашивают привязку параметров запроса (RFx) на предложения к предопределенному шаблону содержания предложения, который определяет оставшиеся из полей данных подробных сведений запроса (RFx) на предложения. Поля данных шаблона предложения могут быть заполнены значениями по умолчанию или требовать ввода пользователя. Система 100 может предоставить пользователю варианты (если сконфигурировано на уровне предприятия) включения или отключения конкретных позиций предложения, как пользователь посчитает подходящим для своих конкретных потребностей. Например, пользователь может иметь дело с базой поставщиков, которая установлена и известна. В таких случаях пользователь может решить отключить некоторые позиции предложения, которые требуют конкретную информацию потенциальных вторичных поставщиков услуг по соглашению SLA, например, относительно опроса о предыстории или качестве. Напротив, у первичного поставщика услуг по соглашению SLA также есть возможность через конфигурацию заблокировать конкретные позиции предложения, которые не смогут затем быть отключены пользователем во время процесса разработки запроса (RFx) на предложения.
После выбора соответствующих позиций запроса (RFx) на предложения пользователь, если это применимо, вводит необходимую информацию, чтобы удовлетворить заданному запросу (RFx) на предложения, обрабатываемому на этапе 1222. Простые примеры этого ввода представляют собой спецификацию администратора предложений первичного поставщика услуг по соглашению SLA или требуемый срок ответа на запрос о предложении. После завершения желаемого ввода пользователь сохраняет модификации данных на этапе 1224. Хотя это не изображено в потоке 1200 процесса, у пользователя может быть возможность редактирования. Система 100 может использовать методики управления кодом состояния, чтобы предоставить возможность временного хранения, с тем чтобы обработка данных могла иметь место в другое время или другим пользователем.
Как только вся информация заполнена в запросе (RFx) на предложения, на этапах 1226-1232 составляется список ходатайств запросов (RFx) на предложения. Этап 1226 становится доступным для пользователя первичного поставщика услуг по соглашению SLA после завершения и сохранения ввода желаемых позиций предложения. В этот момент система 100 предоставляет ранее неактивный элемент управления отправки запроса (RFx) на предложения. Элемент управления активизируется на этапе 1228, и на этапе 1230 пользователю предоставляют список всех одобренных вторичных поставщиков услуг по соглашению SLA, присоединенных к запросу (RFx) на предложения, которые авторизованы, например, предоставлять семейство бизнеса и территориальный охват. Систематическое присоединение обычно является сопоставлением в базе данных семейств бизнеса квалификации для предоставления услуг и географических параметров, установленных на ранее описанном этапе 1070.
На этапе 1232 пользователь первичного поставщика услуг по соглашению SLA выбирает либо всех вторичных поставщиков услуг по соглашению SLA, содержащихся в потенциальном списке ходатайства с запросами (RFx) на предложения, либо их подмножество. Обычно имеется несколько инструментальных средств для поддержки принятия решения, чтобы помочь пользователю в этом процессе выбора, которые предоставляют пользователю ценную информацию о вторичном поставщике услуг по соглашению SLA, относящуюся, например, к отслеженному качеству, ценам и штрафным показателям по предоставлению услуг по соглашению SLA.
После выбора и сохранения пользователем желаемых вторичных поставщиков услуг по соглашению SLA на этапе 1234 система 100 запрашивает у пользователя отправку запроса (RFx) на предложения этим выбранным вторичным поставщикам услуг по соглашению SLA. На этапе 1236 пользователь активизирует элемент управления отправки запроса (RFx) на предложения, что приводит к транслированию запроса (RFx) на предложения на этапе 1238 и уведомлению вторичных поставщиков услуг по соглашению SLA, например, через электронную почту и обновление панели управления на этапе 1240. Список рассылки, установленный пользователем, сохраняется, например, в таблице 47. Первичная информация записи с подробными сведениями по предоставлению услуг по соглашению SLA, которая будет использоваться в процессе запроса (RFx) на предложения, сохраняется, например, в таблицах 37-39.
На фиг.12B на этапе 1244 вторичные поставщики услуг по соглашению SLA обращаются к запросу (RFx) на предложения и выполняют любые определенные шаблоном соглашения для обработки предложения. Этап 1244 обычно активизируется через графический интерфейс пользователя (GUI) приложения. Выполнение соглашений поставщика, таких как, но без ограничения, соглашение о неразглашении (NDA) и соглашение об интеллектуальной собственности (IP), как было раскрыто ранее; поэтому конкретные элементы управления сделаны доступными для пользователя вторичного поставщика услуг по соглашению SLA, посредством которых соглашения могут быть интерактивно выполнены или нет. Для потока 1200 процесса предполагается, что вторичные поставщики услуг по соглашению SLA действительно выполнят любые предусмотренные соглашения, установленные первичным поставщиком услуг по соглашению SLA.
На этапе 1246 вторичный поставщик услуг по соглашению SLA обеспечивает ввод всем функциям запроса (RFx) на предложения приложения, которые требуют ответа. Система 100 обычно использует простой счетчик ответов на позиции предложения, который не позволяет предоставить ответ на запрос о предложении, пока все необходимые позиции ответа на запрос о предложении не будут заполнены. Кроме того, система 100 обычно активизирует функцию проверки правильности данных, при которой позиции ответа на запрос о предложении могут быть заполнены только правильным объектом данных и в предписанном формате. Подробные сведения ответа на запрос (RFx) на предложения сохраняются, например, в таблицах 48-49 и 90-91.
На этапе 1248 вторичные поставщики услуг по соглашению SLA создают записи представления трудовых ресурсов, применимые к профилю работника по предоставлению услуг по соглашению SLA. Хотя этап 1248 обычно имеет место как подпроцесс в пределах этапа 1246, процесс представления ресурсов по соглашению SLA выделен как отдельный этап процесса для ясности. Во время этапа 1248 вторичный поставщик услуг по соглашению SLA обычно использует предоставленный графический интерфейс пользователя (GUI), чтобы получать доступ к любым соответствующим профилям ресурса по соглашению SLA, содержащимся в запросе (RFx) на предложения, и создавать представления ресурсов, присоединенные к профилям ресурса по соглашению SLA. Информация о представлении содержится, например, в таблице 50. Система 100 может быть выполнена с возможностью разместить общую библиотеку трудовых ресурсов вторичных поставщиков услуг по соглашению SLA, которая будет использоваться в режиме привязки, посредством которой ресурсы сопоставлены с профилями квалификаций для предоставления услуг по соглашению SLA, в макрорежиме в противоположность микро-режиму (индивидуальные запросы (RFx)), изображенному здесь. Этот режим может быть полезен, когда отдельный первичный поставщик услуг по соглашению SLA не заинтересован в проведении конкурентных запросов (RFx) на предложения, а предпочитает работать со вторичными поставщиками услуг по соглашению SLA, используя генеральное соглашение.
В другом режиме представление ресурсов имеет место после процесса ответа на запрос (RFx) на предложения, а не во время ответа на запрос (RFx) на предложения. Это может иметь место, когда запросы (RFx) на предложения выданы, чтобы покрыть предоставляемые услуги через несколько месяцев в будущем. В таких случаях представление конкретных трудовых ресурсов во время фактического процесса предложения может быть неуместным. Специалисты в области техники поймут, что изображенный иллюстративный процесс не является единственным режимом привязки ресурсов вторичного поставщика услуг по соглашению SLA к требованиям клиента соглашения SLA.
На этапе 1250 вторичные поставщики услуг по соглашению SLA сохраняют информационные параметры и представляют ответ на запрос о предложении первичному поставщику услуг по соглашению SLA. Этап 1250 представляет собой заполнение запрошенной информации ответа на запрос о предложении, тем самым давая возможность вторичному поставщику услуг по соглашению SLA представить свой завершенный ответ на запрос (RFx) на предложения. Этап 1250 приводит к обновлению записей и инициализирует систематические уведомления приложения для любых предварительно сконфигурированных пользователей на этапе 1252.
Этапы 1254-1258 представляют собой процесс размещения ответа на запрос о предложении первичного поставщика услуг по соглашению SLA. На этапе 1254 первичный поставщик услуг по соглашению SLA делает обзор ответов на запросы о предложении от вторичных поставщиков услуг по соглашению SLA. На этапе 1256 первичный поставщик услуг по соглашению SLA принимает желательные ответы на запросы о предложении. На этапе 1258 вторичные поставщики услуг по соглашению SLA уведомляются, например, через обновление системы и электронную почту, о присуждениях предложений.
Предполагая, что по меньшей мере один ответ на запрос о предложении вторичного поставщика услуг по соглашению SLA достоин присуждения предложения, первичный поставщик услуг по соглашению SLA определяет присуждение по меньшей мере одной записи ответа на запрос о предложении. Первичный поставщик услуг по соглашению SLA может присудить несколько ответов на запрос на предложения и выдать присуждения для всех позиций ответа на предложения или для их подмножества. Например, вторичный поставщик услуг по соглашению SLA может быть назначен для одной области охвата обслуживания, применимой к предложению, но не для другой. В другом примере вторичный поставщик услуг по соглашению SLA может быть назначен на конкретное время охвата предоставления услуг по соглашению SLA, но не на другое. Это имеет место, например, если встречается ответ на запрос на предложения, указывающий непомерно высокий тариф для предоставления услуг в нерабочие часы или в выходные дни. Размещение присуждений ответов на запросы на предложения может являться переменным и гибким, давая возможность первичному поставщику услуг по соглашению SLA использовать оптимальные методы снабжения во время этого процесса.
Этапы 1260-1270 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA создает требования на приобретение из присужденных ответов на запросы на предложения вторичного поставщика услуг по соглашению SLA. На этапе 1260 у первичного поставщика услуг по соглашению SLA запрашивают создание требований на приобретение для вторичного поставщика услуг по соглашению SLA. На этапе 1262 первичный поставщик услуг по соглашению SLA активизирует элемент управления для создания требования на приобретение. На этапе 1264 система 100 создает требования на приобретение с использованием унаследованных данных ответа на запрос на предложения. На этапе 1266 система 100 предоставляет список всех вторичных поставщиков услуг по соглашению SLA, которые приняли присуждение предложений, применимому к запросу (RFx) на предложения. На этапе 1268 первичный поставщик услуг по соглашению SLA делает обзор созданных требований на приобретение для проверки точности и, если нужно, модификации. На этапе 1270 первичный поставщик услуг по соглашению SLA сохраняет требования на приобретение и представляет их вторичному поставщику услуг по соглашению SLA для рассмотрения/одобрения.
Аналогично отчету о несвязанных подробных сведениях по предоставлению услуг по соглашению SLA система 100, используя управляемые базой данных коды состояния, может обеспечить первичному поставщику услуг по соглашению SLA вывод отчета всех присуждений ответов на запрос на предложения, которые должны быть обработаны в заказы на приобретение. Иллюстрированный процесс показывает линейный процесс, который переходит с присуждения на обработку требований на приобретение, в целях простоты описания. В некоторых вариантах воплощения процесс может являться независимым и обрабатываться в альтернативное время и, возможно, альтернативным персоналом.
Активизируется модуль обработки требований на приобретение, и пользователю первичного поставщика услуг по соглашению SLA предоставляют список всех ожидающих обработки присуждений ответов на запрос на предложения, если проиллюстрированный процесс был выполнен в независимом режиме. Процесс иллюстрирует линейный режим, как было отмечено, таким образом, пользователь не должен был выбирать ожидающие присужденные ответы на запрос на предложения. Так как процесс предполагает процесс реквизиции, происходящий из отдельного набора записей запросов (RFx) на предложения, система 100 создает требования на приобретение с информацией, которая будет содержаться в требованиях, унаследованной от присужденных записей ответов на запрос на предложения. Требования на приобретение в режиме по умолчанию создаются по одному на каждого вторичного поставщика услуг по соглашению SLA и могут содержать несколько позиций при необходимости. Это имеет место, если соответствующее присуждение запроса (RFx) на предложения было присоединено к нескольким записям с подробными сведениями по предоставлению услуг по соглашению SLA.
Как только требования на приобретение были созданы, система 100 предоставляет первичному поставщику услуг по соглашению SLA возможность, например, делать обзор или добавлять комментарий. Когда пользователь первичного поставщика услуг по соглашению SLA удовлетворен информацией, содержащейся в требовании на приобретение, он сохраняет и одобряет требования на приобретение. Это действие инициализирует обновления кодов статуса в системе 100, а также выдачу системных уведомлений соответствующим вторичным поставщикам услуг по соглашению SLA.
Этапы 1272-1278 представляют собой обработку вторичным поставщиком услуг по соглашению SLA требований на приобретение, созданных первичным поставщиком услуг по соглашению SLA. Система 100 потоков поддерживает переменный рабочий поток одобрения вторичным поставщиком услуг по соглашению SLA. Рабочий поток, относящийся к несогласиям по поводу данных или информации, которые могут произойти во время процесса, в явном виде здесь не показан.
Во время этапов 1272-1278 вторичный поставщик услуг по соглашению SLA производит обзор, одобряет и повторно представляет обратно первичному поставщику услуг по соглашению SLA завершенное требование на приобретение. На этапе 1272 вторичный поставщик услуг по соглашению SLA уведомляется относительно ожидающего требования на приобретение. На этапе 1274 вторичный поставщик услуг по соглашению SLA делает обзор подробных сведений требования на приобретение и одобряет требование на приобретение. На этапе 1276 система 100 представляет одобренное требование на приобретение первичному поставщику услуг по соглашению SLA. На этапе 1278 первичный поставщик услуг по соглашению SLA уведомляется относительно одобренной поставки.
На этапе 1280 первичный поставщик услуг по соглашению SLA обращается к одобренному требованию на приобретение. На этапе 1282 первичный поставщик услуг по соглашению SLA активизирует элемент управления для создания заказа на приобретение. На этапе 1284 система 100 создает заказ на приобретение. На этапе 1286 первичный поставщик услуг по соглашению SLA определяет внутренний номер заказа на приобретение и одобряет заказ на приобретение. На этапе 1288 вторичный поставщик услуг по соглашению SLA уведомляется относительно одобренного заказа на приобретение. На этапе 1290 заказ на приобретение делается доступным вторичному поставщику услуг по соглашению SLA. В иллюстративных целях представлена простая структура таблиц базы данных, которая использует одни и те же таблицы 51 и 52 как репозитории для данных и требования на приобретение, и заказа на приобретение.
Фиг.13 является схемой базы данных, которая поддерживает функцию снабжения. Схема 1300 базы данных представляет собой высокоуровневую иллюстративную схему базы данных, которая поддерживает функциональные возможности обработки данных, описанные до этого. Специалисты в области техники поймут, что непрерывный информационный поток продолжается через разворачивающийся сеанс обработки данных, обеспечивая полную возможность соединения деловой информации модуля снабжения назад с функцией основных данных. В различных вариантах воплощения техническое решение с наследуемой информацией уменьшает ввод пользователя, устраняет ошибки ввода данных и обеспечивает оптимизированную возможность контроля.
Следующий процесс полной методологии представляет собой функцию управления предоставлением услуг трудовых ресурсов, которая включает в себя: 1) предоставление первичному поставщику услуг по соглашению SLA возможности обзора и одобрения размещения представленных кандидатур ответов на запросы (RFx) на предложения; 2) предоставление первичному поставщику услуг по соглашению SLA возможности систематического уведомления о размещении/статусе представленных кандидатур ответов на запросы (RFx) на предложения вторичному поставщику услуг по соглашению SLA; 3) предоставление возможности создания записи ресурса по предоставлению услуг по соглашению SLA первичным поставщиком услуг по соглашению SLA после одобрения/принятия представленных кандидатур ответов на запросы (RFx) на предложения; 4) предоставление доступа в систему для трудовых ресурсов вторичного поставщика услуг по соглашению SLA; 5) предоставление возможности систематического выполнения соглашения трудовыми ресурсами вторичного поставщика услуг по соглашению SLA; 6) предоставление возможности администрирования/конфигурирования календаря наличия работ вторичным поставщиком услуг по соглашению SLA и одобренными трудовыми ресурсами; 7) предоставление первичному поставщику услуг по соглашению SLA возможности логистической оценки охвата времени; и 8) предоставление первичному поставщику услуг по соглашению SLA функции проактивного посредничества для периодов недоступности для трудовых ресурсов. Период недоступности представляет собой период, в течение которого конкретный трудовой ресурс или коллективная группа ресурсов не доступны.
Обычно режим, в котором производится привлечение сторонних исполнителей для предоставления услуг по соглашению SLA, таков, что природа административного управления заключается в том, что первичный поставщик услуг по соглашению SLA достигает соглашений с руководством или продавцами предприятия вторичного поставщика услуг по соглашению SLA при минимальном бизнес-анализе, проводимом на уровне трудовых ресурсов для предоставления услуг по соглашению SLA, или вообще без такого анализа. Это не подразумевает, что игнорируется вся должная старательность или историческая оценка качества работы вторичных поставщиков услуг по соглашению SLA, а скорее является общим положением дел относительно того, на каком уровне предпринимается управление бизнесом. В конечном счете, качество и успех предоставления услуг по соглашению SLA клиентам являются результатом качества, возможностей и доступности трудовых ресурсов для предоставления услуг по соглашению SLA вместе с адекватным логистическим планированием и взаимодействием.
Фиг.14A-14B являются блок-схемами последовательности операций, которые иллюстрируют высокоуровневые процессы, применимые к управлению предоставлением услуг трудовых ресурсов. На фиг.14A поток 1400 процесса начинается на этапе 1402. Этапы 1402-1406 иллюстрируют процесс, посредством которого первичные поставщики услуг по соглашению SLA систематически уведомляются относительно любых существующих заказов на приобретение вторичных поставщиков услуг по соглашению SLA, которые не связаны по меньшей мере с одной записью назначения ресурса для предоставления услуг по соглашению SLA. На этапе 1402 пользователь первичного поставщика услуг по соглашению SLA обращается к модулю управления трудовыми ресурсами. На этапе 1404 первичный поставщик услуг по соглашению SLA переходит в управляемом с помощью меню графическом интерфейсе пользователя (GUI) к выбору не назначенных заказов на приобретение вторичных поставщиков услуг по соглашению SLA. На этапе 1406 система 100 предоставляет отчет в виде списка, сгруппированного по вторичным поставщикам услуг по соглашению SLA и заказам на приобретение. Хотя это явно не изображено, будет иметься доступ к управлению записями, когда уже существует привязка назначения работника. Модификация записей в случае необходимых изменений персонала логически диктует такую функциональную возможность.
Этапы 1408-1416 адресованы к выбору пользователем первичного поставщика услуг по соглашению SLA желательных трудовых ресурсов для предоставления услуг по соглашению SLA, и их процесс изображает режим, посредством которого вторичный поставщик услуг по соглашению SLA ранее представлял записи ресурсов во время процесса запросов (RFx) на предложения. Этот процесс может быть переменным, и хотя это явно не изображено, для вторичных поставщиков услуг по соглашению SLA доступны функциональные возможности для передачи записей ресурсов для обзора в значительной степени в любое время во время процесса обзора. Это имеет место, когда эти представленные записи ресурсов были неудовлетворительными или больше не доступными для назначения по любой из причин. На этапе 1408 пользователь выбирает соответствующую запись вторичного поставщика услуг по соглашению SLA и активизирует элемент управления для управления трудовыми ресурсами. На этапе 1410 система 100 предоставляет пользователю список всех представлений ресурсов вторичного поставщика услуг по соглашению SLA, применимых к привязанному исходному ответу на запрос (RFx) на предложения. На этапе 1412 система 100 предоставляет управление пользователю для перехода по ссылке на подробные сведения представления ресурсов. На этапе 1414 пользователь выбирает через графический интерфейс пользователя (GUI) те конкретные трудовые ресурсы, которые желательны для обеспечения охвата предоставления услуг по соглашению SLA. На этапе 1416 пользователь сохраняет набор записей одобренных ресурсов, и система 100 отправляет уведомление об этом вторичному поставщику услуг по соглашению SLA.
Этот процесс дает возможность пользователю первичного поставщика услуг по соглашению SLA исследовать подробные сведения представления (представлений) и в соответствии с этим сделать свой желаемый выбор. Хотя есть много дополнительных возможных, не раскрытых здесь в явном виде признаков, специалисты в области техники поймут, что процесс обзора и выбора в результате дает первичному поставщику услуг по соглашению SLA контроль над ресурсами, которые, в конечном счете, будут предоставлять услуги от его имени. Таблица 53 содержит подробные сведения, относящиеся к вводу в систему трудовых ресурсов, в то время как подробные сведения о назначениях содержатся в таблице 54.
После выбора желаемых ресурсов система 100 активизирует процесс обратного подтверждения на этапах 1418-1424, посредством которого вторичный поставщик услуг по соглашению SLA может проверить наличие ресурсов и свое желание присоединить ресурс к соответствующему назначению по предоставлению услуг. На этапе 1418 система 100 создает записи назначения трудовых ресурсов для одобренных ресурсов с состоянием ожидания. На этапе 1420 вторичный поставщик услуг по соглашению SLA подтверждает одобрение назначения ресурса через графический интерфейс пользователя (GUI). На этапе 1422 первичный поставщик услуг по соглашению SLA уведомляется относительно подтверждения назначения, например, через системное уведомление. На этапе 1424 вторичному поставщику услуг по соглашению SLA предоставляются мандаты доступа к системе для соответствующих ресурсов.
Этапы 1426-1430 адресованы к вводу в административную систему трудового ресурса для предоставления услуг по соглашению SLA. Первичным поставщиком услуг по соглашению SLA могут быть настроены различные защитные соглашения с трудовым ресурсом после доступа в систему, такие как, например, соглашение о неразглашении (NDA), соглашение о защите интеллектуальной собственности (IP) и подтверждение временных трудовых соглашений. Этот процесс изображает положительное действие трудового ресурса. Другие результаты произошли бы в случае, если соглашение с трудовым ресурсом не было своевременно выполнено или возможно даже из-за несогласия. На этапе 1426 ресурсы вторичного поставщика услуг по соглашению SLA обращаются к системе 100 с предоставленными мандатами. На этапе 1428 ресурсы вторичного поставщика услуг по соглашению SLA выполняют настроенные интерактивные соглашения. На этапе 1430 системные уведомления отправляются как первичному, так и вторичному поставщикам услуг по соглашению SLA.
Предполагая, что с вводом в систему трудовых ресурсов все проходит благополучно, следующий процесс предусматривает конфигурацию календаря доступности трудового ресурса на этапах 1432-1442. На этапе 1432 у вторичного поставщика услуг по соглашению SLA запрашивают обращение и конфигурирование календаря трудовых ресурсов. На этапе 1434 вторичный поставщик услуг по соглашению SLA обращается к модулю календаря трудовых ресурсов. На этапе 1436 вторичный поставщик услуг по соглашению SLA обращается к конкретной записи трудового ресурса. На этапе 1438 вторичный поставщик услуг по соглашению SLA обеспечивает стандартные периоды недоступности и общие периоды доступности трудового ресурса. На этапе 1440 вторичный поставщик услуг по соглашению SLA повторяет этапы 1434-1438 для всех соответствующих назначенных трудовых ресурсов, присоединенных к соответствующему вторичному поставщику услуг по соглашению SLA. На этапе 1442 после завершения всех конфигураций календаря ресурсов вторичный поставщик услуг по соглашению SLA представляет конфигурации календаря назначений заказов на приобретение первичному поставщику услуг по соглашению SLA.
В этой стадии процесса 1400 желаемые трудовые ресурсы были назначены для соответствующих действий по предоставлению услуг по соглашению SLA. Поток 1400 процесса включает в себя сложное и эффективное логистическое средство, посредством которого периоды охвата трудовых ресурсов могут быть введены в систему 100 и проанализированы с целью поддержки планирования. На высоком уровне при управлении предоставлением услуг трудовых ресурсов, в соответствии с различными вариантами воплощения, у вторичных поставщиков услуг по соглашению SLA запрашивают ввод основного плана назначенных трудовых ресурсов для предоставления услуг по соглашению SLA. Базовая конфигурация обычно предусматривает назначение стандартных периодов недоступности, таких как выходные дни или ночное время или заданные периоды отпусков или праздников. Нельзя ожидать, что трудовой ресурс будет доступен по вызову в течение 24 часов каждый день; напротив, вторичный поставщик услуг по соглашению SLA очень часто может быть ответственным за 24-часовой временной охват.
Как правило, запрос (RFx) на предложения содержит информацию относительно периодов времени охвата по договору; с другой стороны, следует также понимать, что в большинстве случаев предоставление услуг с полным периодом охвата обычно влечет за собой использование нескольких трудовых ресурсов и часто нескольких вторичных поставщиков услуг по соглашению SLA. Таким образом, во время следующего процесса, проиллюстрированного на этапах 1445-1456, первичный поставщик услуг по соглашению SLA определяет какие-либо потенциальные промежутки в предоставлении услуг. В идеальном случае первичный поставщик услуг по соглашению SLA устанавливает: 1) полный логистический охват каждым вторичным поставщиком услуг по соглашению SLA; или 2) полный составной охват несколькими вторичными поставщиками услуг по соглашению SLA. Система 100 дает возможность первичному поставщику услуг по соглашению SLA статистически проверить правильность вышеупомянутых сценариев через ввод/загрузку данных о доступности по календарю трудовых ресурсов и анализ данных. Эта статистическая проверка правильности находится в центре внимания этапов 1445-1456.
От этапа 1442 выполнение переходит на этап 1445 на фиг.14B. На этапе 1445 пользователь первичного поставщика услуг по соглашению SLA обращается к списку назначений ресурсов для заказов на приобретение в модуле управления трудовыми ресурсами. На этапе 1448 пользователь первичного поставщика услуг по соглашению SLA активизирует управляющий элемент для оценки охвата. На этапе 1450 система 100 предоставляет первичному поставщику услуг по соглашению SLA отчет, идентифицирующий любые потенциальные периоды с отсутствием охвата или времена недоступности. На этапе 1452 система 100 предоставляет пользователю первичного поставщика услуг по соглашению SLA возможность для оценки совокупного охвата всеми вторичными поставщиками услуг по соглашению SLA для соответствующего охвата конкретных записей с подробными сведениями по предоставлению услуг клиента соглашения SLA. На этапе 1454 пользователь первичного поставщика услуг по соглашению SLA выполняет отчет оценки совокупного охвата. На этапе 1456 система 100 предоставляет первичному поставщику услуг по соглашению SLA отчет, идентифицирующий любые потенциальные периоды с отсутствием охвата или недоступностью в совокупном охвате.
Поскольку система 100 измеряет время в логически сегментированных единицах базы данных, обеспечить отчет об охвате трудовых ресурсов для предоставлению услуг по соглашению SLA является простой задачей. Анализ охвата может быть выполнен либо на индивидуальном, либо на совокупном уровне вторичных поставщиков услуг по соглашению SLA. Таким образом, может быть сделан обзор анализа охвата индивидуального вторичного поставщика услуг по соглашению SLA или периоды охвата ресурсов нескольких вторичных поставщиков услуг по соглашению SLA, присоединенные к одной записи с подробными сведениями по предоставлению услуг клиента соглашения SLA, могут быть рассмотрены все вместе. Первичному поставщику услуг по соглашению SLA предоставляются данные, необходимые для определения, адекватен ли охват. Кроме того, может быть сделана идентификация любых конкретных вторичных поставщиков услуг по соглашению SLA, чей ввод данных либо не соответствует временам охвата, установленным во время процесса запроса (RFx) на предложения, либо слишком ограничен в области охвата, определенной первичным поставщиком услуг по соглашению SLA. В других вариантах воплощения может использоваться более сложная система управления базой данных, которая блокируется в периоды охвата ответа на запросы (RFx) на предложения и, таким образом, заставляет соответствующих вторичных поставщиков услуг по соглашению SLA заполнить записи календаря трудовых ресурсов соответствующим образом.
Этапы 1458-1466 имеют отношение к интерфейсу, предоставленному пользователю первичного поставщика услуг по соглашению SLA, посредством которого индивидуальные периоды недоступности для вторичных поставщиков услуг по соглашению SLA могут быть выбраны и переправлены соответствующим вторичным поставщикам услуг по соглашению SLA с комментарием относительно ожидаемых модификаций расписания, которые ожидаются пользователем первичного поставщика услуг по соглашению SLA. Позитивный результат включает в себя модификации охвата существующих записей календаря или представление дополнительных трудовых ресурсов для заполнения потенциальных промежутков охвата. В случае новых представлений предпринимается процесс обзора представлений, описанный выше. Процесс анализа и диагностики может быть инициализирован столько раз, сколько первичный поставщик услуг по соглашению SLA считает необходимым для обеспечения адекватного охвата предоставления услуг по соглашению SLA.
На фиг.14B на этапе 1458 система 100 предоставляет первичному поставщику услуг по соглашению SLA возможность выпустить запрос модификации охвата вторичным поставщикам услуг по соглашению SLA по выбору. На этапе 1460 пользователь первичного поставщика услуг по соглашению SLA выбирает соответствующих вторичных поставщиков услуг по соглашению SLA. На этапе 1462 пользователь первичного поставщика услуг по соглашению SLA выбирает конкретные периоды недоступности, идентифицированные как нуждающиеся в обзоре, для каждого идентифицированного вторичного поставщика услуг по соглашению SLA. На этапе 1464 либо производятся модификации календаря существующих назначенных трудовых ресурсов для уменьшения периодов недоступности, либо могут быть осуществлены дополнительные представления трудовых ресурсов для поддержания области охвата, либо дополнительные вторичные поставщики услуг по соглашению SLA могут быть затребованы через запросы (RFx) на предложения. На этапе 1466 независимо от необходимых модификаций относительно периодов недоступности индивидуальные вторичные поставщики услуг по соглашению SLA администрируют все свои собственные расписания трудовых ресурсов, с тем чтобы была предоставлена оценка доступности ресурса в реальном времени. Библиотека данных для использования вместе с функциональными возможностями управления календарем трудовых ресурсов хранится в таблицах, таких как, например, таблицы 58-63. Фактические подробные сведения данных календаря, применимые к индивидуальному трудовому ресурсу, хранятся в таблицах, таких как, например, таблицы 55-57.
Фиг.15 является блок-схемой последовательности операций, которая иллюстрирует процесс конфигурации календаря трудовых ресурсов. Три первичных режима конфигурации, установленные в потоке 1500 процесса, представляют собой: 1) режим стандартного расписания работ; 2) режим нестандартного расписания работ; и 3) режим ежедневных действий. Стандартное расписание работ представляет собой стандартное ожидаемое расписание. В этом режиме вторичный поставщик услуг по соглашению SLA устанавливает базовое расписание для конкретного трудового ресурса, который присоединен к назначению заказа на приобретение. Ввод в этом режиме устанавливает стандартные рабочие дни и стандартные часы доступности работника.
На фиг.15 поток 1500 начинается на этапе 1502, на котором пользователь вторичного поставщика услуг по соглашению SLA обращается к модулю управления трудовыми ресурсами. На этапе 1505 пользователь вторичного поставщика услуг по соглашению SLA переходит в управляемом с помощью меню графическом интерфейсе пользователя (GUI) к выбору записей назначенных трудовых ресурсов. На этапе 1508 система 100 предоставляет отчет со списком всех назначенных трудовых ресурсов. На этапе 1510 пользователь выбирает желаемую запись трудовых ресурсов. На этапе 1512 система 100 предоставляет отчет со списком подходящих подробных сведений и ссылку на соответствующий календарь. На этапе 1515 пользователь активизирует элемент управления для календаря. На этапе 1518 система 100 предоставляет меню, которое может включать следующие варианты: (1) сконфигурировать стандартное расписание; (2) сконфигурировать другие запланированные периоды недоступности; и (3) поддерживать ежедневные действия. На этапе 1520 пользователь активизирует управляющий элемент для конфигурирования стандартного расписания. На этапе 1522 пользователю предоставляют отображение еженедельного календаря, которое представляет, например, все семь дней недели. На этапе 1525 пользователь обеспечивает ввод и сохраняет его. На этапе 1528 пользователь активизирует управляющий элемент для конфигурирования других запланированных периодов недоступности.
В типичном варианте воплощения пользователь должен лишь активизировать селективную кнопку периода недоступности для всех дней, которые представляют стандартные выходные дни, и сохранить настройки. Пользователю также предоставляется отображение каждого из дней, не входящих в период недоступности, с получасовыми интервалами времени, хотя это представляет собой стандартную конфигурацию, которая в случае необходимости может быть изменена до минутных интервалов. Каждый интервал сопровождается двумя элементами управлениями: 1) начало; и 2) окончание. Пользователь конфигурирует каждый день, устанавливая время начала и время окончания. После завершения пользователь сохраняет настройки, и параметры стандартного календаря сохраняются в базе данных для соответствующего ресурса для предоставления услуг по соглашению SLA. Ввод нестандартного расписания работ влечет за собой назначение других запланированных периодов недоступности. Примерами запланированных периодов недоступности такого типа являются отпуск или стандартные праздники компании. Эти периоды по самой своей природе являются переменными и поэтому нестандартны.
На этапе 1530 система 100 запрашивает у пользователя: (1) определение праздников; и (2) определение запланированного отпуска. На этапе 1532 пользователь обеспечивает ввод и сохраняет его. У пользователя запрашивают конфигурирование запланированных праздников и отпусков. Пользователь активизирует элемент управления, и ему предоставляется, например, отображение годового календаря, разделенное на 12 месяцев. Пользователь выбирает соответствующий месяц, после чего ему предоставляется детализированное отображение месяца, разделенное на дни. Затем пользователь выбирает соответствующий день и сохраняет ввод. У пользователя запрашивают назначить выбранный день либо как праздник, либо как отпускной день. Пользователь сохраняет ввод и продолжает до тех пор, пока конфигурация не будет завершена.
На этапе 1535 система 100 предоставляет уведомление пользователю о том, что календарь ресурсов для предоставления услуг теперь является активным. На этапе 1538 система 100 предоставляет уведомления первичному поставщику услуг по соглашению SLA и пользователю трудовых ресурсов вторичного поставщика услуг по соглашению SLA, что календарь ресурсов для предоставления услуг теперь является активным. На этапе 1540 пользователь вторичного поставщика услуг по соглашению SLA активизирует элемент управления для поддержания ежедневных действий. На этапе 1542 определяется, имеются ли у конкретного ресурса какие-либо запланированные вызовы по предоставлению услуг. Если ответ для определения на этапе 1542 положительный, выполнение переходит на этап 1545.
Планирование ежедневных действий представляет собой ввод, применимый к продолжающейся/непрерывной календарной доступности, применимой к индивидуальному трудовому ресурсу. Природа применения труда сторонних исполнителей означает, что обычно никто из работников не ожидает, когда один конкретный клиент сделает вызов с проблемой. Таким образом, обычно конкретный трудовой ресурс используется для предоставления услуг нескольким клиентам соглашения SLA и также нескольким первичным поставщикам услуг по соглашению SLA. Этот календарный режим делает возможным механизм отслеживания текущих трудовых ресурсов, посредством которого можно администрировать конкретными периодами недоступности в системе 100 для обеспечения отчетности о доступности в реальном времени.
Во время этапов 1545-1555 пользователь перемещается в точку, из которой можно получить доступ к ежедневному администрированию периодов недоступности. На этапе 1545 система 100 запрашивает у пользователя выбор: рабочую неделю и рабочий день. На этапе 1548 система 100 запрашивает у пользователя выбор: начало периода недоступности. На этапе 1550 система 100 запрашивает у пользователя ввод ожидаемой продолжительности заявки на обслуживание, присоединенной к соответствующим трудовым ресурсам. На этапе 1552 система 100 запрашивает у пользователя заполнение полей с дополнительными подробными сведениями. На этапе 1555 система 100 сохраняет ввод из этапов 1545-1552. Соответствующий ресурс для предоставления услуг по соглашению SLA назначается пользователем вторичного поставщика услуг по соглашению SLA, и пользователю предоставляется по умолчанию представление текущего ежедневного календаря; обычно с получасовыми интервалами. Пользователь выбирает время начала и время окончания ежедневной деятельности и сохраняет настройку. Ввод сохраняется, и ресурс для предоставления услуг по соглашению SLA показывается как недоступный для отправки во время этого периода времени. Подробные данные календаря хранятся в таблицах, таких как, например, таблицы 55-57. Таблица 55 является управляющей таблицей, которая хранит идентифицирующую информацию трудового ресурса и соответствующего назначения заказа на приобретение. Для одного трудового ресурса могут иметься несколько периодов охвата назначения. Таблица 56 хранит основное расписание работ, в то время как таблица 57 хранит подробные сведения о нестандартных периодах недоступности, а также ежедневные периоды недоступности, администрируемые вторичным поставщиком услуг по соглашению SLA.
Фиг.16 иллюстрирует схему базы данных, которая поддерживает функцию управления предоставлением услуг трудовых ресурсов. Специалисты в области техники поймут, что различные варианты воплощения предоставляют первичному поставщику услуг по соглашению SLA логистическую видимость обеспечения трудовых ресурсов и функциональные возможности планирования, необходимые для удовлетворения требованиям соглашения SLA со своими клиентами. Хотя это не изображено явно, конфигурация систематических уведомлений с предупреждениями первичному поставщику услуг по соглашению SLA в случае полной недоступности трудовых ресурсов для одной или более записей с подробными сведениями по предоставлению услуг клиентам соглашения SLA является естественным признаком для обеспечения услуг. В различных вариантах воплощения могут быть реализованы улучшенные конфигурации с тем, чтобы могли быть инициализированы систематические действия и соответствующие уведомления для противодействия промежуткам во временном охвате предоставления услуг клиентам соглашения SLA.
Предыдущие действия являлись предварительными условиями, ведущими к логистическому администрированию и управлению предоставлением услуг по соглашению SLA и проверке качества соответствующими клиентами соглашения SLA. Первичные темы, затрагиваемые в связи с отправкой услуг по соглашению SLA, включают в себя: 1) предоставление функциональных возможностей запроса на предоставление услуг, посредством которых клиент соглашения SLA может создать и представить запрос на предоставление услуг первичному поставщику услуг по соглашению SLA; 2) предоставление первичному поставщику услуг по соглашению SLA средств системных запросов, которые могут использоваться для вывода списка сконфигурированных вторичных поставщиков услуг по соглашению SLA, а также их соответствующих расценок и доступности подходящих трудовых ресурсов, назначенных для отправки услуг; 3) предоставление первичному поставщику услуг по соглашению SLA возможности выбора конкретного доступного ресурса для предоставления услуг по соглашению SLA в качестве желаемого для потенциальной отправки; 4) предоставление первичному поставщику услуг по соглашению SLA возможность систематически представлять запись запроса на отправку услуг вторичному поставщику услуг по соглашению SLA; 5) предоставление вторичному поставщику услуг по соглашению SLA возможности подтверждать доступность ресурса и последующую отправку ресурса первичному поставщику услуг по соглашению SLA; и 6) предоставление первичному поставщику услуг по соглашению SLA возможности подтверждать отправку ресурса клиенту соглашения SLA.
Фиг.17A является блок-схемой последовательности операций, иллюстрирующей поток процесса, применимый к функции логистического обеспечения и администрирования. Поток процесса начинается на этапе 1702. Этапы 1702-1720 изображают процесс, посредством которого клиент соглашения SLA представляет запрос на предоставление услуг первичному поставщику услуг по соглашению SLA. На этапе 1702 пользователь клиента соглашения SLA обращается к системе 100, управляет соответствующим меню и активизирует элемент управления создания запроса на предоставление услуг. Этап 1702 явным образом не указывает ограничения пользователя или использования конкретных прав авторизации; однако различные варианты воплощения изобретения могут интегрировать роли пользователей и заданные права/разрешения для обработки данных, если так желательно для клиента соглашения SLA. На этапе 1705 система 100 запрашивает у пользователя определение местоположения клиента соглашения SLA и идентификатора. Этап 1705 указывает выбор пользователем клиента соглашения SLA местоположения для начала процесса запроса. Это лишь типовой режим, а не внутреннее ограничение. Например, процесс запроса может начинаться со ссылки на договор или поиска конкретной записи с подробными сведениями по предоставлению услуг. На этапе 1708 система 100 предоставляет пользователю отображение списка договоров и соответствующих услуг, предоставляемых по соглашению SLA. Этап 1708 расширен с помощью фиг.17B, которая изображает простой графический интерфейс пользователя (GUI) в форме, в которую встроены активные элементы управления, дающие пользователю клиента соглашения SLA доступ к критической информации о предоставлении услуг по соглашению SLA. Пользователь клиента соглашения SLA либо немедленно распознает соответствующую запись с подробными сведениями по предоставлению услуг по соглашению SLA, либо использует встроенные элементы управления, чтобы с помощью обзора информации убедиться, какие подходящие записи с подробными сведениями по предоставлению услуг по соглашению SLA требуют обеспечения. На фиг.17B все элементы управления являются потенциально активными, чтобы предоставить пользователю представления с дополнительной информацией. Однако элемент 1708-A9 является неактивным или затененным до тех пор, пока не будет выбрана по меньшей мере одна запись в элементе 1708-A1. Каждая встроенная ссылка предоставляет пользователю новый пользовательский интерфейс (UI), представляющий информацию, применимую к заголовку столбца. Пользователь клиента соглашения SLA использует независимые переключатели, обеспеченные для назначения того, какие записи с подробными сведениями по предоставлению услуг по соглашению SLA будут связаны с запросом на предоставление услуг по соглашению SLA. Выбор конкретных записей на этапе 1710 инициирует дополнительную форму ввода пользовательского интерфейса (UI), посредством которой пользователь клиента соглашения SLA может добавить комментарий на этапе 1712, если это желательно.
На этапе 1710 пользователь выбирает желаемые записи предоставления услуг по соглашению SLA и сохраняет выбор. На этапе 1712 системный графический интерфейс пользователя (GUI) предоставляет пользователю дополнительные поля ввода. Пользователь завершает дополнительный ввод и сохраняет его. Специалисты в области техники поймут с помощью обзора таблиц 64-66, что в типичном варианте воплощения во время процесса, изображенного на этапах 1702-1712, пользователь клиента соглашения SLA может обеспечить ввод в минимальное количество полей, поскольку все остальные поля являются заданными по умолчанию данными. Вариант с дополнительными полями ввода может быть легко добавлен к базе данных, если природа работы по предоставлению услуг гарантировала такие добавления элементов данных.
На этапе 1715 система 100 запрашивает у пользователя представление запроса на предоставление услуг по соглашению SLA поставщику услуг по соглашению SLA. Хотя это явно не изображенный на этапе 1715, в различных вариантах воплощения пользователь клиента соглашения SLA может иметь возможность переменным образом направлять запрос на предоставление услуг назначенному пользователю первичного поставщика услуг по соглашению SLA, такому как, например, менеджер по технической поддержке, если деловые требования диктуют такой сценарий. Подробные сведения, применимые к этапам 1702-1715, хранятся в таблицах, таких как, например, таблицы 64-67. На этапе 1720 пользователь представляет запрос на предоставление услуг по соглашению SLA поставщику услуг по соглашению SLA.
Этапы 1721-1728 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA получает систематический доступ к подробным сведениям вторичного поставщика услуг по соглашению SLA, присоединенным к запросу на предоставление услуг клиента соглашения SLA. На этапе 1721 система 100 уведомляет первичного поставщика услуг по соглашению SLA о недавно представленном запросе на предоставление услуг по соглашению SLA. Хотя это явно не изображено на этапе 1721, ответная реакция на запрос на предоставление услуг обычно администрируется и управляется в системе 100, это означает, что поле dispatchresponseTimeID в таблице 30 является активным и используется для создания уведомлений об отправке, когда обработка запроса на предоставление услуг соответствующими сторонами не соответствует предварительно сконфигурированным ожиданиям или планам. Кроме того, в различных вариантах воплощения используется функция расширенной роли пользователя, чтобы в некоторых случаях направлять/назначать уведомления об отправке конкретным пользователям первичного поставщика услуг по соглашению SLA. С другой стороны, пользователи клиента соглашения SLA оповещаются относительно состояния обработки запроса на предоставление услуг.
На этапе 1723 пользователь первичного поставщика услуг по соглашению SLA обращается к новому запросу на предоставление услуг по соглашению SLA, например, через графический интерфейс пользователя (GUI). На этапе 1725 пользователь первичного поставщика услуг по соглашению SLA активизирует элемент управления для отображения охвата предоставления услуг. На этапе 1728 система 100 предоставляет пользователю отображение списка авторизованных вторичных поставщиков услуг по соглашению SLA и соответствующих одобренных трудовых ресурсов, авторизованных оказывать услуги для соответствующей записи с подробными сведениями по предоставлению услуг. Отображение обычно показывает, например, доступность, расценки, показатели обслуживания. Этап 1728 предоставляет пользователю соответствующего первичного поставщика услуг по соглашению SLA обобщенное представление присоединенных вторичных поставщиков услуг, как показано на фиг.17C.
На фиг.17C столбец 1728-A1 является просто вариантом выбора с помощью независимых переключателей для пользователя первичного поставщика услуг по соглашению SLA. Однако этот вариант обычно является неактивным или затененным для пользователя, когда количество доступных ресурсов в элементе 1728-A5 является равным нулю. Когда пользователь запускает активный элемент управления в столбце 1728-A5, предоставляется отображение списка соответствующих доступных трудовых ресурсов и общие сведения об их доступности по календарю. Деловая информация, доступная для пользователя первичного поставщика услуг по соглашению SLA, не только приводит к отображению ресурсов для потенциальной отправки, но также обеспечивает окно для критической финансовой информации и информации по качеству, давая возможность оптимального процесса принятия решений.
Этапы 1730-1732 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA выбирает по желанию предпочтительные конкретные доступные ресурсы для предоставления услуг по соглашению SLA, которые должны быть доставлены в местоположение соответствующего клиента соглашения SLA. На этапе 1730 пользователь первичного поставщика услуг по соглашению SLA выбирает желаемую запись вторичного поставщика услуг по соглашению SLA и предпочтение трудовых ресурсов, если доступно несколько ресурсов. На этапе 1732 пользователь первичного поставщика услуг по соглашению SLA сохраняет выбор. Хотя этап 1730 изображает иллюстративный процесс, в котором выбрана только одна запись вторичного поставщика услуг по соглашению SLA, могут быть выбраны несколько записей. Пользователь первичного поставщика услуг по соглашению SLA может выбрать несколько вторичных поставщиков услуг по соглашению SLA, чтобы принять запись запроса на отправку услуг. В этом случае система 100 в типичном варианте воплощения обрабатывает рабочий поток по принципу "первый на входе - первый на выходе". В другом сценарии ситуация может являться критической по природе и в обязательном порядке требовать отправки всех доступных ресурсов независимо от присоединения вторичного поставщика услуг по соглашению SLA. Различные варианты воплощения изобретения могут сделать возможными множественные запросы на отправку ресурсов для предоставления услуг по соглашению SLA от нескольких вторичных поставщиков услуг по соглашению SLA.
После выбора записи вторичного поставщика услуг по соглашению SLA дальнейшие функциональные возможности приложения могут дать возможность пользователю углубиться в более подробные сведения, и при желании пользователь первичного поставщика услуг по соглашению SLA может назначить предпочтительный ресурс для предоставления услуг по соглашению SLA или список ресурсов, желаемых для предоставления услуг по заявке. Имеется много причин относительно того, почему может быть желателен конкретный ресурс. Причины включают в себя, например, благоприятные исторические качественные показатели или предпочтение клиента соглашения SLA. Информация хранится в таблицах, таких как, например, таблицы 68 и 69. Данные, хранящиеся в таблицах, таких как таблицы 70-71, служат исходными данными для поля в таблице 68. Идентифицирующая информация любых предпочтительных ресурсов для предоставления услуг по соглашению SLA, намеченных для отправки, хранится, например, в таблице 69.
Этапы 1735-1738 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA выпускает запрос на отправку услуг. На этапе 1735 у пользователя первичного поставщика услуг по соглашению SLA запрашивают отправку запроса на отправку услуг. На этапе 1738 пользователь первичного поставщика услуг по соглашению SLA представляет запрос на отправку услуг соответствующему вторичному поставщику услуг по соглашению SLA.
Этапы 1740-1755 изображают процесс, посредством которого вторичный поставщик услуг по соглашению SLA систематически подтверждает доступность ресурса и отправку ресурса соответствующему первичному поставщику услуг по соглашению SLA. На этапе 1740 система 100 уведомляет вторичного поставщика услуг по соглашению SLA относительно нового запроса на отправку услуг. На этапе 1742 пользователь вторичного поставщика услуг по соглашению SLA обращается к новому запросу на отправку услуг. В системе 100, хотя это не изображено, этапы 1740-1742 можно администрировать и управлять ими более жестко, как было указано на этапе 1721.
На этапе 1745 пользователь вторичного поставщика услуг по соглашению SLA проверяет доступность трудовых ресурсов. Этап 1745 изображает только положительный результат относительно доступности ресурса. Специалисты в области техники поймут, что это не всегда будет иметь место; однако транзакции вследствие отрицательного результата опущены, чтобы не загромождать существенные признаки различных вариантов воплощения изобретения. В случае отрицательной доступности ресурса вопреки администрируемым календарным данным в типичном варианте воплощения система 100 отслеживает такие неточности вторичного поставщика услуг по соглашению SLA в целях измерения показателей качества и вычисляет коэффициент неэффективности вторичного поставщика услуг по соглашению SLA относительно возможностей и доступности его ресурсов. После проверки доступности ресурса система 100 обычно запрашивает у вторичного поставщика услуг по соглашению SLA отправку верификации отправки соответствующему первичному поставщику услуг по соглашению SLA. Дополнительные подробные сведения вводятся и сохраняются во время этого процесса, который после сохранения загружает новую запись в таблицу 72 базы данных.
На этапе 1748 система 100 запрашивает у вторичного поставщика услуг по соглашению SLA отправку уведомления об отправке трудовых ресурсов первичному поставщику услуг по соглашению SLA. На этапе 1750 пользователь вторичного поставщика услуг по соглашению SLA активизирует элемент управления для представления проверки отправки. На этапе 1752 вторичный поставщик услуг по соглашению SLA заполняет дополнительные поля и сохраняет ввод. На этапе 1755 вторичный поставщик услуг по соглашению SLA представляет запись отправки.
Во время этапов 1740-1755 вторичного поставщика услуг по соглашению SLA заставляют установить идентифицирующую информацию ресурса для предоставления услуг по соглашению SLA, время отправки и предполагаемое время прибытия во время этапа 1745 с помощью ввода, сохраняемого, например, в таблице 72. Кроме того, информация о местоположении относительно доступа к оборудованию, указания и т.д. обеспечиваются и подтверждаются во время этого процесса вторичным поставщиком услуг по соглашению SLA. Поскольку этапы 1740-1755 заставляют вторичного поставщика услуг по соглашению SLA взять на себя обязательства относительно логистической отправки трудовых ресурсов, эти этапы также предоставляют вторичному поставщику услуг по соглашению SLA критическую логистическую информацию о клиенте соглашения SLA для надлежащей отправки услуг.
Этапы 1758-1768 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA систематически уведомляет клиента соглашения SLA об отправке ресурса для предоставления услуг по соглашению SLA в местоположение для предоставления услуг. На этапе 1758 система 100 уведомляет первичного поставщика услуг по соглашению SLA о записи поставки. На этапе 1760 первичный поставщик услуг по соглашению SLA обращается к записи проверки поставки и подтверждает прием. На этапе 1762 система 100 запрашивает у первичного поставщика услуг по соглашению SLA отправку уведомления о проверке поставки клиенту соглашения SLA. На этапе 1765 пользователь первичного поставщика услуг по соглашению SLA активизирует элемент управления для отправки проверки поставки. На этапе 1768 система 100 отправляет уведомления клиенту соглашения SLA, и запись поставки делается доступной в интерактивном режиме. При желании этапы 1758-1760 могут администрироваться по времени и ими можно управлять через конфигурацию экспедирования. Процесс этапов 1758-1768 завершает цепь, которая начинается с проблемы клиента соглашения SLA и заканчивается уведомлением пользователя клиента соглашения SLA относительно предполагаемого времени прибытия ресурсов для предоставления услуг.
Фиг.18 иллюстрирует схему базы данных, которая поддерживает функцию логистики предоставления услуг и администрирования. Специалисты в области техники поймут, что различные варианты воплощения изобретения используют поддерживающую схему данных и обработку с помощью приложения, которые не только вносят крайне нужную видимость и логистическое управление в деятельность по предоставлению услуг, но также интегрируют необходимый персонал и взаимодействия в единую платформу. Хотя это не изображено явно, в различных вариантов воплощения могут быть установлены конфигурации, посредством которых может быть введена улучшенная автоматизация для систематических запросов на предоставление услуг и доставки трудовых ресурсов. Такой сценарий часто является желательным, когда соответствующий персонал первичного поставщика услуг по соглашению SLA не доступен для ответа на запрос клиента соглашения SLA на предоставление услуг.
Фиг.19A-19B иллюстрируют процессы, применимые к приемке работы и гарантии качества по предоставлению услуг по соглашению SLA. Описание, связанное с фиг.19A-19B, сосредоточено на отслеживании и документировании соответствующих действий по предоставлению услуг, которые имеют место в соответствии с доставкой услуг. При сценарии, в котором либо вторичный поставщик услуг по соглашению SLA, либо клиент по соглашению SLA обращается к первичному поставщику услуг по соглашению SLA для уведомления о том, что отправленный ресурс для предоставления услуг не смог прибыть в местоположение предоставления услуг, система 100 может включать в себя функциональные возможности для обработки такого сценария. Пользователю клиента соглашения SLA могут быть предоставлены функциональные возможности для инициализации процесса рабочего потока для неявки или после прямого взаимодействия с пользователем первичного поставщика услуг по соглашению SLA, например, телефонного звонка, процесс рабочего потока может быть запущен повторно с этапа 1725 обзора доступных ресурсов для предоставления услуг (фиг.17C), при этом ссылаясь на уже сохраненные в базе данных записи, применимые к рассматриваемой работе по предоставлению услуг.
Описание относительно фиг.19A-19B сосредоточено на: 1) предоставлении ресурсу вторичного поставщика услуг по соглашению SLA доступа к функции свидетельства об оказании услуг, посредством которой в систему 100 вводятся подробные сведения, относящиеся, например, к выполненной работе, использованным материалам и затратам времени, в ответ на запрос на отправку услуг; 2) предоставлении вторичному поставщику услуг по соглашению SLA возможности представлять свидетельство об оказании услуг первичному поставщику услуг по соглашению SLA для рассмотрения и одобрения; 3) предоставлении первичному поставщику услуг по соглашению SLA возможности делать обзор и одобрять свидетельство об оказании услуг от вторичного поставщика услуг по соглашению SLA; 4) предоставлении первичному поставщику услуг по соглашению SLA возможности создавать свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA со ссылкой на свидетельство об оказании услуг вторичного поставщика услуг по соглашению SLA и представлять его клиенту соглашения SLA для рассмотрения и размещения; 5) предоставлении клиенту соглашения SLA возможности обрабатывать свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA и предоставлять информацию оценки качества; и 6) предоставлении систематических уведомлений пользователям первичного и вторичного поставщиков услуг по соглашению SLA после обработки свидетельства об оказании услуг клиентом соглашения SLA.
На фиг.19A поток 1900 процесса начинается на этапе 1902, на котором ресурс вторичного поставщика услуг по соглашению SLA выполняет заявку на предоставлению услуг. Этапы 1904-1918 изображают процесс обработки свидетельства об оказании услуг ресурса для предоставления услуг по соглашению SLA. На этапе 1904 ресурс вторичного поставщика услуг по соглашению SLA переходит в управляемом с помощью меню графическом интерфейсе пользователя (GUI) к выбору функции свидетельства о выполнении работы. На этапе 1906 система 100 предоставляет отчет с отображением списка всех записей отправки услуг с открытым состоянием. Отображение списка, представленное ресурсу для предоставления услуг по соглашению SLA, обычно может обрабатывать множественные назначения (например, множественные назначения, в которых превалируют открытые записи отправки).
На этапе 1908 пользователь выбирает желаемую запись предоставления услуг. Действие на этапе 1908 приводит к тому, что система 100 предоставляет пользовательский интерфейс (UI) свидетельства об оказании услуг на этапе 1910. Пользовательский интерфейс (UI) обычно наследует все подходящие подробные сведения, присоединенные к набору записей отправки услуг. Таким образом, ресурс предоставления услуг по соглашению SLA обычно должен выполнить только ввод данных, соответствующих выполненной работе по предоставлению услуг, этот ввод выполняется на этапе 1912. После сохранения ввода на этапе 1914 система 100 сохраняет подробные сведения об операции, например, в таблицах 73-77.
Как только запись свидетельства сохранена, у ресурса для предоставления услуг по соглашению SLA запрашивают представление свидетельства предварительно заданному пользователю вторичного поставщика услуг по соглашению SLA для рассмотрения и последующей обработки операций на этапах 1916 и 1918. Действие, предпринятое на этапе 1918, инициирует уведомление предварительно заданному пользователю вторичного поставщика услуг по соглашению SLA на этапе 1920.
На этапе 1922 пользователь обращается к новому свидетельству о предоставлении услуг из меню или по предоставленной ссылке. Этап 1922 изображает процесс, посредством которого пользователь вторичного поставщика услуг по соглашению SLA переходит к специальному функциональному модулю приложения, который предоставляет возможность обработки свидетельства об оказании услуг. Доступ возможен через навигацию по стандартному меню или посредством активизации конкретной ссылки уведомлений на панели управления, применимой к операции свидетельства.
Этапы 1924-1934 изображают обработку свидетельства об оказании услуг вторичным поставщиком услуг по соглашению SLA. На этапе 1924 система 100 предоставляет пользователю графический интерфейс пользователя (GUI) для свидетельства. Свидетельство содержит расценки, установленные в заказе на приобретение вторичного поставщика услуг по соглашению SLA. Система 100 предоставляет пользователю вторичного поставщика услуг по соглашению SLA информацию свидетельства, представленную ресурсом для предоставления услуг по соглашению SLA, а также информацию, собранную из соответствующего заказа на приобретение вторичного поставщика услуг по соглашению SLA и соответствующих позиций заказа на приобретение. Этап 1924 прежде всего является этапом проверки, обеспечивающим вторичному поставщику услуг по соглашению SLA осведомленность о совершенной работе и рассмотрение подробных сведений заказа на приобретение, содержащихся в свидетельстве.
На этапе 1926 пользователь проверяет через системный ввод подробные сведения свидетельства и сохраняет его. Этап 1926 является физической проверкой информации, сохраненной в базе данных, пользователем вторичного поставщика услуг по соглашению SLA. Действие проверки приводит к тому, что система запрашивает у пользователя вторичного поставщика услуг по соглашению SLA выполнение ввода какой-либо соответствующей оценки налогообложения на этапе 1928. После завершения ввода данных налогообложения или проверки, является ли оценка налогообложения предварительно настроенной, пользователь вторичного поставщика услуг по соглашению SLA сохраняет параметры данных на этапе 1930.
Этапы 1932-1934 приводят к предоставлению свидетельства о приемке работы заданному пользователю первичного поставщика услуг по соглашению SLA. На этапе 1932 система 100 запрашивает у пользователя предоставление свидетельства первичному поставщику услуг по соглашению SLA. На этапе 1934 пользователь предоставляет свидетельство первичному поставщику услуг по соглашению SLA для рассмотрения/одобрения.
Этапы 1936-1944 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA делает обзор и размещение предоставленного свидетельства об оказании услуг вторичного поставщика услуг по соглашению SLA. Этапы 1936-1938 предоставляют заданному пользователю первичного поставщика услуг по соглашению SLA возможность получить доступ к предоставленному свидетельству об оказании услуг вторичного поставщика услуг по соглашению SLA. На этапе 1936 система 100 уведомляет первичного поставщика услуг по соглашению SLA о новом свидетельстве о предоставлении услуг. На этапе 1938 пользователь первичного поставщика услуг по соглашению SLA обращается к новому свидетельству о предоставлении услуг из меню или по предоставленной ссылке.
На этапе 1940 система 100 предоставляет пользователю графический интерфейс пользователя (GUI) для свидетельства. Свидетельство содержит расценки, установленные в заказе на приобретение вторичного поставщика услуг по соглашению SLA. Пользователю первичного поставщика услуг по соглашению SLA обычно предоставляется интерфейс с отображением записей, детализирующий все подходящие подробные сведения, применимые к деятельности по предоставлению услуг, а также заказ на приобретение вторичного поставщика услуг по соглашению SLA. На этапе 1942 у пользователя имеется вариант либо одобрить, либо не одобрить предоставленную там подробную информацию. Изображено положительное действие, посредством которого предоставленное свидетельство об оказании услуг одобряется на этапе 1944. После этапа 1944 пользователь вторичного поставщика услуг по соглашению SLA систематически уведомляется относительно одобрения предоставленного свидетельства об оказании услуг.
Этапы 1946-1954 изображают процесс, посредством которого первичный поставщик услуг по соглашению SLA может вставить подробные сведения из одобренного свидетельства об оказании услуг вторичного поставщика услуг по соглашению SLA в отдельное свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA, которое унаследует соответствующие данные заказа на приобретение клиента соглашения SLA. Как только на этапе 1944 происходит одобрение свидетельства, у пользователя первичного поставщика услуг по соглашению SLA запрашивают создание нового свидетельства об оказании услуг на этапе 1946, например, посредством активизации предоставленного элемента управления в пользовательском интерфейсе (UI). Изображенный процесс имеет линейную природу только в иллюстративных целях. Создание нового свидетельства об оказании услуг может выполняться переменным образом в другое время и другими сотрудниками в соответствии с конфигурацией, выполненной первичным поставщиком услуг по соглашению SLA. Пользователь создает новое свидетельство об оказании услуг на этапе 1948, что инициирует процесс и интеграцию данных, аналогичные тем, которые происходят при обработке вторичным поставщиком услуг по соглашению SLA свидетельства об оказании услуг на этапах 1908-1910.
На фиг.19B на этапе 1950 система 100 предоставляет пользователю графический интерфейс пользователя (GUI) для свидетельства. Свидетельство содержит расценки, установленные в заказе на приобретение клиента соглашения SLA. Система 100 создает свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA, которое содержит подробные сведения, применимые к физически выполненной работе по предоставлению услуг, а также соответствующие подробные финансовые сведения относительно заказа на приобретение клиента соглашения SLA.
Для клиента соглашения SLA не обязательно имеются деловые основания, чтобы видеть любые подходящие подробные сведения, применимые ко вторичному поставщику услуг по соглашению SLA, за исключением данных относительно работы по предоставлению услуг, введенных ресурсом для предоставления услуг по соглашению SLA. Таким образом, создается новое свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA, который содержит подробные сведения, относящиеся к взаимоотношениям между клиентом соглашения SLA и первичным поставщиком услуг по соглашению SLA.
Этапы 1952-1954 изображают действия, предпринимаемые пользователем первичного поставщика услуг по соглашению SLA, для одобрения и предоставления завершенного свидетельства об оказании услуг первичного поставщика услуг по соглашению SLA клиенту соглашения SLA. Хотя система 100 создает новое свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA, данные фактически являются подмножеством данных, содержащихся в таблицах 73-77. Специалисты в области техники поймут, что простая альтернатива для структуры базы данных может сохранять эти данные в отдельных таблицах с использованием соединений по ссылке в базе данных.
Этапы 1956-1988 изображают этапы, выполняемые клиентом соглашения SLA при обработке предоставленного свидетельства об оказании услуг первичного поставщика услуг по соглашению SLA. На этапе 1956 система 100 уведомляет клиента соглашения SLA о новом свидетельстве о предоставлении услуг. На этапе 1958 система 100 предоставляет пользователю графический интерфейс пользователя (GUI) для свидетельства. Свидетельство содержит расценки, установленные в заказе на приобретение клиента соглашения SLA.
На этапе 1960 у пользователя клиента соглашения SLA запрашивают одобрение или отклонение предоставленного свидетельства об оказании услуг. Хотя это не изображено явно, в различных вариантах воплощения клиент соглашения SLA может добавить расширенные роли пользователей и рабочий поток и сделать конфигурацию одобрения более сложной и надежной. В предположении, что пользователь клиента соглашения SLA на этапе 1960 одобряет информацию, содержащуюся в свидетельстве об оказании услуг, система 100 запрашивает у пользователя на этапе 1964 активизацию элемента управления, которая начинает сеанс оценки качества на этапах 1964-1966. На этапе 1964 система 100 запрашивает у пользователя выполнение оценки качества. На этапе 1966 пользователь активизирует управляющий элемент сеанса оценки качества. Как только сеанс оценки качества начат, система 100 на этапе 1968 предоставляет пользователю форму графического интерфейса пользователя (GUI), дающую возможность клиенту соглашения SLA оценить качество и своевременность работы по предоставлению услуг, а также своевременность и административную простоту логистики по предоставлению услуг, которая предшествовала физическому предоставлению услуг.
После завершения оценки у клиента соглашения SLA запрашивают сохранить свой ввод на этапе 1970. Это действие инициирует обновление системы 100 на этапе 1972 и последующие систематические уведомления об одобрении соответствующим пользователям первичного и вторичного поставщиков услуг по соглашению SLA на этапе 1974.
Если на этапе 1960 пользователь клиента соглашения SLA отклоняет свидетельство об оказании услуг, выполнение переходит на этап 1978. На этапе 1978 у пользователя клиента соглашения SLA запрашивают выполнение оценки при отклонении, так в данный момент имеется спор относительно аспектов предоставления услуг.
На этапе 1980 система 100 предоставляет пользователю клиента соглашения SLA графический интерфейс пользователя (GUI), предоставляющий возможность ввода конкретных возражений, а также комментариев для обоснования таких возражений. На этапе 1982 пользователь клиента соглашения SLA выполняет свою оценку и сохраняет ввод. Это действие инициирует сохранение записи системой 100 на этапе 1984 и последующее уведомление об отклонении соответствующим пользователям первичного и вторичного поставщиков услуг по соглашению SLA на этапе 1986. Этап 1988 представляет собой начальную точку, которая может быть проектирована в целях обработки приложения, являющейся бесконечным циклом и посредством которой может быть введен процесс прерывания и собран и сохранен ввод данных от нескольких сторон. Подробные сведения, относящиеся к отклонению свидетельства, сохраняются в таблице, такой как, например, таблица 81, в то время как сами коды отклонения хранятся в таблице, такой как, например, таблица 80.
Фиг.20 иллюстрирует схему базы данных, которая поддерживает приемку работы по предоставлению услуг по соглашению SLA и гарантию качества.
Оценка штрафов по соглашению SLA является вопросом сравнения по базе данных, при условии, что нарушение предоставления услуг обычно происходит по причине: 1) несвоевременности отправки; 2) своевременности прибытия для предоставления услуг; или 3) неисполнения услуг. В случае сценариев 1) и 2) систематическое использование управления кодами статусов, меток даты/времени для записей и проверка пользователей адекватным образом отслеживает эти аспекты предоставления услуг. Что касается сценария 3), оценка штрафа является функцией размещения свидетельства клиента соглашения SLA. Обсуждение функции выставления счета и оплаты относится к функции обработки финансовых данных системы 100. Информационный поток упорядочен следующим образом:
к информации о договоре клиента соглашения SLA привязываются
записи с подробными сведениями по предоставлению услуг, к которым привязываются
записи заказа на приобретение клиента соглашения SLA, к которым привязываются
запросы (RFx) на предложения первичного поставщика услуг по соглашению SLA, к которым привязываются
ответы на запросы (RFx) на предложения вторичного поставщика услуг по соглашению SLA, к которым привязываются
присуждения запросов (RFx) на предложения, к которым привязываются
записи заказа на приобретение вторичного поставщика услуг по соглашению SLA.
Описанный выше информационный поток завершает административную настройку, которая приводит к охвату предоставления услуг по соглашению SLA.
Дальнейший информационный поток представляет собой следующее:
к запросу на предоставление услуг клиента соглашения SLA (сформированный со ссылкой на запись с подробными сведениями по предоставлению услуг) привязывается
запрос на отправку услуг первичного поставщика услуг по соглашению SLA, к которому привязывается
отправка услуг вторичного поставщика услуг по соглашению SLA, к которой привязывается
свидетельство об оказании услуг ресурса для предоставления услуг, к которому привязывается
свидетельство об оказании услуг вторичного поставщика услуг по соглашению SLA, к которому привязывается
свидетельство об оказании услуг первичного поставщика услуг по соглашению SLA, к которому привязывается
обработка свидетельства об оказании услуг клиента соглашения SLA.
Различные элементы, рассмотренные ниже, включают в себя: 1) сконфигурированное систематическое извлечение одобренных клиентом соглашения SLA свидетельств об оказании услуг; 2) систематическое формирование файлов счетов на оплату первичным поставщиком услуг по соглашению SLA клиенту соглашения SLA; 3) систематическое формирование файлов счетов на оплату вторичным поставщиком услуг по соглашению SLA первичному поставщику услуг по соглашению SLA; 4) средство загрузки данных квитанции об оплате первичному поставщику услуг по соглашению SLA после оплаты клиента соглашения SLA; и 5) средство выпуска платежа первичного поставщика услуг по соглашению SLA вторичному поставщику услуг по соглашению SLA, обусловленного платежом клиента соглашения SLA.
Фиг.21 является блок-схемой последовательности операций, которая иллюстрирует процессы, относящиеся к функции оплаты счетов. Этапы 2102-2105 изображают основное извлечение одобренных свидетельств об оказании услуг клиента соглашения SLA. Это извлечение является конфигурируемым во время установки программы и предусматривает назначение периода цикла извлечения. Информация набора записей для извлечения хранится в таблицах, таких как, например, таблицы 82-83. Таблица 83 содержит идентифицирующую информацию индивидуальных позиций свидетельства об оказании услуг; таким образом, процедура извлечения проверяет не существование записей в этой таблице как обоснование для извлечения данных; это означает, что записи не извлекаются избыточно при ошибке. Хотя это не изображено явно, извлечение записей может быть сконфигурировано более надежным образом, посредством чего для воздействия на извлечение конкретных наборов записей могут быть введены различные факторы, такие как условия оплаты и периодичность учета.
Этапы 2108-2110 изображают процессы, посредством которых файлы счетов на оплату формируются из извлеченных данных. На этапе 2108 система 100 производит заданные конфигурацией файлы счетов на оплату для каждого клиента соглашения SLA. На этапе 2110 система 100 производит заданные конфигурацией файлы счетов на оплату для каждого вторичного поставщика услуг по соглашению SLA. Поскольку система 100 ориентирована на поддержку полного жизненного цикла операций предприятия, файлы формируются как для выставления счетов клиенту соглашения SLA от имени первичного поставщика услуг по соглашению SLA, так и для выставления счетов первичному поставщику услуг по соглашению SLA от имени вторичного поставщика услуг по соглашению SLA. Формируется несколько файлов счетов, когда в пределах периода цикла извлечения имелись операции для более чем одного клиента соглашения SLA и более чем одного вторичного поставщика услуг по соглашению SLA.
Этапы 2112 - 2128 вместе представляют собой обработку файлов счетов на оплату первичного поставщика услуг по соглашению SLA. Эти этапы изображают процесс управления, посредством которого назначенные пользователи первичного поставщика услуг по соглашению SLA могут обратиться и сделать обзор сформированных файлов. Процесс является конфигурируемым и в различных вариантах воплощения может быть опущен, если первичный поставщик услуг по соглашению SLA принял решение не выполнять процесс обзора и выпуска. На этапе 2112 система 100 уведомляет авторизованного пользователя первичного поставщика услуг по соглашению SLA о том, что новые файлы счетов на оплату доступны для обработки. На этапе 2115 пользователь первичного поставщика услуг по соглашению SLA обращается к модулю финансового управления. На этапе 2118 первичный поставщик услуг по соглашению SLA обращается к файлам счетов на оплату. На этапе 2120 первичный поставщик услуг по соглашению SLA выбирает новый файл счета на оплату. На этапе 2122 система 100 отображает пользователю сводное представление счетов на оплату. На этапе 2125 система 100 запрашивает у пользователя выпуск файлов счетов на оплату. На этапе 2128 пользователь выпускает файлы счетов на оплату. На этапе 2130 система 100 формирует различные файлы счетов на оплату для клиентов соглашения SLA.
После выпуска файлов счетов на оплату на этапе 2128 система 100 формирует проанализированные представления файлов счетов на оплату клиента соглашения SLA и вторичного поставщика услуг по соглашению SLA на этапах 2130-2132. На этапе 2135 назначенные системные пользователи уведомляются о том, что файлы счета на оплату были сделаны доступными для обзора. Файлы доступны для обзора в системе 100 только авторизованным сконфигурированным пользователям. Записи, относящиеся к конкретному предприятию, обычно рассматриваются только пользователями этого предприятия (например, клиента соглашения SLA или вторичного поставщика услуг по соглашению SLA). По желанию файлы счета могут быть дополнительно переданы, например, через электронный обмен данными (EDI), если деловые способы оправдывают такие режимы работы.
Этапы 2138-2148 изображают процесс, посредством которого вторичный поставщик услуг по соглашению SLA и клиент соглашения SLA подтверждают прием файлов. Подтверждение клиента соглашения SLA никоим образом не связано с подтверждением приема файла вторичного поставщика услуг по соглашению SLA и не зависит от него. При использовании технологий электронного обмена данными (EDI) и электронного перевода средств (EFT) это может быть процесс с молчаливой операцией, посредством которого средства перемещаются на основе одобрения свидетельства об оказании услуг. В конце концов, финансовые операции будут ограничены элементами исходных данных, которые уже прошли различные процессы одобрения.
На этапе 2138 авторизованный пользователь соглашения SLA обращается к модулю финансового управления. На этапе 2140 клиент соглашения SLA обращается к файлам счета на оплату. На этапе 2142 система 100 уведомляет первичного поставщика услуг по соглашению SLA относительно подтверждения приема счета на оплату. На этапе 2145 система 100 запрашивает у пользователя клиента соглашения SLA проверку приема файла счета на оплату. На этапе 2148 пользователь клиента соглашения SLA проверяет файл счета на оплату.
На этапе 2150 клиент соглашения SLA платит первичному поставщику услуг по соглашению SLA в соответствии с договорными условиями. На этапе 2152 первичный поставщик услуг по соглашению SLA загружает данные файла квитанций об оплате в систему 100 или вручную заменяет состояние записи счета на оплату на оплаченное. На этапе 2155 первичный поставщик услуг по соглашению SLA запускает отчет об ожидающих счетах на оплату вторичных поставщиков услуг по соглашению SLA. На этапе 2158 система 100 запрашивает у пользователя авторизовать оплату. На этапе 2160 пользователь авторизует оплату. На этапе 2162 вторичный поставщик услуг по соглашению SLA уведомляется относительно авторизации оплаты. На этапе 2165 первичный поставщик услуг по соглашению SLA платит вторичному поставщику услуг по соглашению SLA в соответствии с договорными условиями. На этапе 2168 первичный поставщик услуг по соглашению SLA загружает данные файла квитанций об оплате в систему 100 или вручную заменяет состояние записей счетов на оплату вторичного поставщика услуг по соглашению SLA на оплаченное. На этапе 2170 данные об оплате доступны в интерактивном режиме для авторизованных пользователей.
Фиг.22 иллюстрирует схему базы данных, которая поддерживает функцию оплаты счетов.
Фиг.23 является макроуровневым представлением функциональных возможностей информационного управления и поддержки принятия решений в соответствии с принципами изобретения. На фиг.23 система 2300 включает в себя базу 2350 данных приложения управления предоставлением услуг по соглашению SLA, которая принимает в качестве ввода информационный поток 2310 обработки основных данных, информационный поток 2320 обработки снабжения, информационный поток 2330 обработки предоставления услуг по соглашению SLA и информационный поток 2340 финансовой обработки.
Выходные этапы из базы 2350 данных приложения управления предоставлением услуг по соглашению SLA включает в себя выходной этап 2355 для планирования требований клиента соглашения SLA по предоставлению услуг и стратегического анализа охвата, выходной этап 2360 для показателей производительности поставщика услуг по соглашению SLA и обеспечения требований для текущей поддержки принятия решений, выходной этап 2365 для анализа договорного предоставления услуг по соглашению SLA, выходной этап 2370 для анализа производительности по гарантийным обязательствам и материалам и выходной этап 2375 для анализа доходности предоставления обеспечения по соглашению SLA и финансового анализа. Что касается, в частности, выходного этапа 2355, первичный поставщик услуг по соглашению SLA, использующий режим сторонних исполнителей, чтобы отвечать требованиям по предоставлению услуг по соглашению SLA для своих клиентов соглашения SLA, может чрезмерно рисковать, если его сеть по предоставлению услуг является неадекватной при начальной установке.
Различные процессы делают возможными функции поддержки принятия решений, присущие выходному этапу 2355. Они включают в себя: 1) перевод информации договора в записи с подробными сведениями по предоставлению услуг; 2) профилирование квалификаций для трудовых ресурсов; 2) сопоставление местоположения клиента соглашения SLA с записями с подробными сведениями по предоставлению услуг; 3) обработка запросов (RFx) на предложения вторичного поставщика услуг по соглашению SLA и ответа на предоставление ресурса для предоставления услуг по соглашению SLA; 4) назначение ресурса для предоставления услуг по соглашению SLA; и 5) конфигурирование и администрирование календаря ресурсов для предоставления услуг по соглашению SLA. Методология обеспечивает первичного поставщика услуг по соглашению SLA средством, посредством которого могут быть идентифицированы разрывы или неэффективность в сети предоставления услуг по соглашению SLA, прежде чем начинается договорной охват предоставления услуг по соглашению SLA. Если у первичного поставщика услуг по соглашению SLA нет никаких ретроспективных данных для анализа, используемая методология может быть привлечена для выявления потенциальных неточностей в предоставлении услуг по соглашению SLA, основанных, например, на: 1) географическом охвате; 2) охвате квалификаций; или 3) охвате периода времени. С другой стороны, если у первичного поставщика услуг по соглашению SLA во время анализа имеются существующие данные относительно частоты предоставления услуг по соглашению SLA, могут быть сформированы более подробные различные представления для расширения области видимости для выявления разрывов в предоставлении услуг.
Значение режима поддержки принятия решений по выявлению рисков выходит за границы его использования во время настройки сети охвата. Как только сеть предоставления услуг сконфигурирована, может быть сконфигурирован сигнальный монитор, который систематически уведомляет первичного поставщика услуг по соглашению SLA, когда все назначенные ресурсы, присоединенные к конкретной записи с подробными сведениями или заявке на приобретение стали недоступны.
Что касается выходного этапа 2360, различные процессы делают возможным анализ производительности предоставления услуг по соглашению SLA. Процессы включают в себя: 1) спецификацию периода времени ответа для предоставления услуг по соглашению SLA, присоединенного к записям с подробными сведениями по предоставлению услуг; 2) интерактивную обработку запроса на предоставление услуг клиента соглашения SLA, присоединенную к записям с подробными сведениями по предоставлению услуг; 3) отслеживаемую обработку запроса на предоставление услуг первичного поставщика услуг по соглашению SLA; 4) отслеживаемую обработку запроса на отправку услуг вторичного поставщика услуг по соглашению SLA; 5) отслеживаемую обработку отправки услуг вторичного поставщика услуг по соглашению SLA; 6) обработку свидетельства об оказании услуг ресурса для предоставления услуг по соглашению SLA; 7) обработку свидетельства об оказании услуг вторичного поставщика услуг по соглашению SLA; 8) обработку свидетельства об оказании услуг первичного поставщика услуг по соглашению SLA; и 9) обработку свидетельства об оказании услуг клиента соглашения SLA. Эти процессы обеспечивают средство сбора подробных сведений, необходимых для адекватного отслеживания и управления производительностью предоставления услуг по соглашению SLA. Специалисты в области техники поймут, что предоставление услуг по соглашению SLA в контексте жизненного цикла предоставления услуг начинается с запроса на предоставление услуг клиента соглашения SLA и достигает высшей точки при оценке, производимой относительно качества работы по предоставлению услуг. При рассмотрении в этом контексте жизненный цикл может быть разбит на подфункции, которые могут быть измерены и проанализированы. Различные варианты воплощения разрешают количественную оценку и анализ относительно, но без ограничения: 1) воздействия первичного поставщика услуг по соглашению SLA на требования к периоду времени предоставления услуг по соглашению SLA; 2) воздействия вторичного поставщика услуг по соглашению SLA на требования к периоду времени предоставления услуг по соглашению SLA; 3) воздействия ресурса для предоставления услуг по соглашению SLA на требования к периоду времени предоставления услуг по соглашению SLA; 4) воздействия для ресурса предоставления услуг по соглашению SLA на требования к предоставлению услуг по соглашению SLA; и 5) удовлетворенности или неудовлетворенности клиента соглашения SLA. Анализ может быть предпринят относительно макропроизводительности вторичного поставщика услуг по соглашению SLA (то есть как предприятия) или его микропроизводительности (то есть, учитывая индивидуальную производительность ресурса для предоставления услуг).
Что касается выходного этапа 2365, различные процессы делают возможным договорной анализ обеспечения соглашения SLA. В отличие от выходного этапа 2360, который делает упор на производительности поставщика, выходной этап 2365 делает упор на обратном представлении, которое обращает внимание на производительность договора по соглашению SLA с точки зрения, например, штрафов за непредоставление услуг по соглашению SLA и целевых показателей предоставления услуг по соглашению SLA. Производительность предоставления услуг по соглашению SLA может быть рассмотрена с разных сторон, таких как совокупная производительность предоставления услуг клиентам соглашения SLA по нескольким договорам или представления совокупной производительности для договоров с несколькими клиентами соглашения SLA, специфичных для некоторого продукта и/или услуги и/или внутренней организации бизнеса.
Кроме того, различные варианты воплощения дают возможность первичному поставщику услуг по соглашению SLA рассмотреть договор уникальным образом. Благодаря функциональным возможностям профилирования квалификаций и управляемым базой данных кодам периодов времени ответа сделаны возможными представления для сравнения договоров, которые легко указывают на общие черты и различия, относящиеся к договорам клиентов соглашения SLA, которые, в частности, предусматривают охват для аналогичных продуктов и/или услуг. Договора по соглашению SLA часто изменяются от одного клиента соглашения SLA к другому. Некоторые различия могут быть маленькими, а некоторые различия могут быть существенным. Различные варианты воплощения обеспечивают средство для демонстрации этих различий таким способом, который является подходящим для обзора и анализа.
Договора по соглашению SLA для конкретной географической области или клиентов соглашения SLA в конкретной отрасли промышленности, такой как, например, передача данных, содержат периоды времени ответа для предоставления услуг, которые представляют собой половину от всех других соответствующих договоров по соглашению SLA. Это главное различие потенциально может быть коррелированно, например, со специфической организацией продаж или условиями договора с откладыванием платежей. Кроме того, различные варианты воплощения обеспечивают прямой вывод показателей, относящихся к воздействию этих различий. Цель системы состоит в том, чтобы предоставить первичному поставщику услуг по соглашению SLA все представления, необходимые не только для предоставления услуг договора по соглашению SLA.
Что касается выходного этапа 2370, аналогичным образом с анализом параметров договора также можно отслеживать и управлять параметрами гарантийных обязательств по услугам и материалам. Что касается этапа 2375, доходность предоставления услуг по соглашению SLA и финансовый анализ относятся, например, к определению цены по договору, определению цены по вторичному обеспечению соглашения SLA, штрафам по предоставлению услуг по соглашению SLA и стоимости материалов. Возможен анализ, который, в конечном счете, стремится улучшить итоговую финансовую производительность бизнеса.
Варианты воплощения настоящего изобретения могут быть реализованы, например, в аппаратных средствах, программном обеспечении (например, выполняться посредством процессора, который исполняет машиночитаемые команды) или их комбинации. Машиночитаемые команды могут представлять собой программный код, загружаемый в память, такую как, например, оперативное запоминающее устройство (ОЗУ), или с носителя данных, такого как, например, постоянное запоминающее устройство (ПЗУ). Например, процессор может быть выполнен с возможностью исполнять программное обеспечение, выполненное с возможностью выполнять последовательность этапов в соответствии с принципами настоящего изобретения. Программное обеспечение может быть выполнено с возможностью находиться на машиночитаемом носителе, таком как, например, магнитный диск в накопителе дисков. Машиночитаемый носитель может также включать в себя, например, карту флэш-памяти, память на основе электронно-стираемого программируемого постоянного запоминающего устройства (ЭСППЗУ), память на цилиндрических магнитных доменах (ЦМД) или постоянное запоминающее устройство (ПЗУ). Программное обеспечение, выполненное с возможностью выполнять способ в соответствии с принципами настоящего изобретения, также может полностью или частично находиться в статической или динамической оперативной памяти или во встроенном программном обеспечении в процессоре (например, в микроконтроллере, микропроцессоре или внутренней памяти микрокомпьютера).
Ниже следуют иллюстративные таблицы 1-91:
<b>1 - Структура</b>
tblSLAPP (Структура)
Столбец
Тип данных
Длина
SLAPPID
uniqueidentifier
16
SLAPPName
varchar
100
SLAPPStatusID
int
4
vParentCompanyName
varchar
100
vBusinessEntityTypeID
int
4
vFedldentity
varchar
50
vYearCorp
varchar
50
vDandBNumber
varchar
50
vDandBRating
varchar
50
vFTEmployees
int
4
vFT_W2_employees
int
4
vURL
varchar
100
vPhone
varchar
50
vFax
varchar
50
vDBECertification
varchar
50
vDBETypeld
int
4
vDBECertificateNumber
varchar
50
vDBECertifyingBody
varchar
50
vEDI
char
1
vEFT
char
1
vClientEmployees
int
4
vCountryID
int
4
vPriorYearRevenues
money
8
vClientCount
numeric
9
NetROI
percentage
4
<b>2 - Структура</b>
tblSLACIientUser (Структура)
Столбец
Тип данных
Длина
SLAPPUserID
uniqueidentifier
16
SLAPPID
uniqueidentifier
16
UserNameLast
varchar
25
UserNameFirst
varchar
25
UserPhone
varchar
50
UserEmail
varchar
50
UserSysLogin
varchar
10
Position/Title
varchar
50
<b>3 - Структура</b>
tblSLAProvisionTypes (Структура)
Столбец
Тип данных
Длина
SLAProvisionTypeID
int
4
SLAProvisionTypeDesc
varchar
50
Status
int
4
<b>3 - Данные</b>
tblSLAProvisionTypes (Данные)
SLAProvisionTypeID
SLAProvisionTypeDesc
Status
1
Purchase_Warranty_Repair
Active
2
Extended_Warranty_Repair
Active
3
Service_Warranty_Repair
Active
4
Preventive_Provisioning
Inactive
5
Non-Contracted_Provisioning
Inactive
<b>4 - Структура</b>
tblSLAProvisionLaborTypes (Структура)
Столбец
Тип данных
Длина
SLAProvisionLaborTypeID
int
4
SLAProvisionLaborTypeDesc
varchar
50
Status
int
4
<b>4 - Данные</b>
tblSLAProvisionLaborTypes (Данные)
SLAProvisionLaborTypeID
SLAProvisionLaborTypeDesc
Status
1
Time_Only
Inactive
2
Time_and_Expense
Inactive
3
Time_and_Material
Active
4
Time_and_Expense_and_Material
Active
5
Fixed_Price
Inactive
6
Labor_Differential
Inactive
<b>5 - Структура</b>
tblSLAProvisionTimes (Структура)
Столбец
Тип данных
Длина
SLAResponseTimeID
int
4
SLAResponseTimeDesc
varchar
500
Qualifier_Desc
varchar
500
<b>5 - Данные</b>
tblSLAProvisionTimes (Данные)
SLAResponseTimeID
SLAResponseTimeDesc
1
Half_Hour
2
Hour
3
End_Of_Business_Day
4
Calendar_Day
5
Next_Biisiness_Day
<b>6 - Структура</b>
tblMaterialMaster (Структура)
Столбец
Тип данных
Длина
MaterialMasterID
int
4
MaterialMasterShortName
varchar
50
MaterialMasterDesc
varchar
500
GoodTypeID
int
4
Manufactured
int
4
Stockedltem
bit
1
LastCost
money
8
LastPurchase/MFGDate
datetime
8
QtyOnHand
numeric
9
ReorderPoint
numeric
9
ReorderQty
numeric
9
<b>7 - Структура</b>
tblMaterialMapLocation (Структура)
Столбец
Тип данных
Длина
MaterialMasterID
int
4
LocationID
int
4
QtyOnHand
numeric
9
LockedQty
numeric
9
StockRecordID
uniqueidentifier
16
<b>8 - Структура</b>
tblLocation (Структура)
Столбец
Тип данных
Длина
SLACIientID
uniqueidentifier
16
LocationID
int
4
LocationTypeID
int
4
LocationName
varchar
50
StreetAddress
varchar
100
GEOCityID
int
4
PostalCodeID
varchar
50
Manned_Facility
bit
1
LocationBadgingRequired
bit
1
GovtClearanceRequired
bit
1
LocationParkingDesc
varchar
500
LocationAccessDesc
varchar
500
LocationFreightDeliveryDesc
varchar
500
EmergencyAccessContactDetails
varchar
500
<b>9 - Структура</b>
tblLocationType (Структура)
Столбец
Тип данных
Длина
LocationTypeID
int
4
Description
varchar
50
Constname
varchar
50
<b>10 - Структура</b>
tblGEOCountry (Структура)
Столбец
Тип данных
Длина
CountryID
int
4
CountryName
varchar
100
CountryAbbr
varchar
50
CurrencyName
varchar
100
CurrencyUnicode
varchar
5
<b>11 - Структура</b>
tblGEORegion (Структура)
Столбец
Тип данных
Длина
Region_ID
int
4
Region Name
varchar
50
Region Type ID
int
4
Country_ID
int
4
<b>12 - Структура</b>
tblGEOCounty (Структура)
Столбец
Тип данных
Длина
County_ID
int
4
County_Name
varchar
100
Region ID
int
4
<b>13 - Структура</b>
tbGEOCities (Структура)
Столбец
Тип данных
Длина
City_ID
int
4
City_Name
varchar
100
County_ID
int
4
<b>14 - Структура</b>
tblBusinessSector (Структура)
Столбец
Тип данных
Длина
BusinessSectorID
int
4
bsDescription
varchar
100
bsVisibleFlag
bit
1
bsSortld
int
4
<b>15 - Структура</b>
tblBusinessArena (Структура)
Столбец
Тип данных
Длина
BusinessArenaID
int
4
baBusinessSectorID
int
4
baBusinessArenaName
varchar
100
baVisibleFlag
char
1
baSortID
int
4
<b>16 - Структура</b>
tblBusinessFamily (Структура)
Столбец
Тип данных
Длина
BusinessFamilyID
int
4
bf BusinessArenaID
int
4
bfBusinessFamilyName
varchar
100
bfVisibleFlag
bit
1
bfSortID
int
4
<b>17 - Структура</b>
tblGeneralFunction (Структура)
Столбец
Тип данных
Длина
GeneralFunctionID
int
4
gfName
varchar
100
gfVisibleFlag
bit
1
gfSortID
int
4
<b>18 - Структура</b>
tblGeneralFunctionBusinessFamily (Структура)
Столбец
Тип данных
Длина
GeneralFunctionID
int
4
BusinessFamilyID
int
4
GFMapBFJD
int
4
<b>19 - Структура</b>
tblBusinessCategory (Структура)
Столбец
Тип данных
Длина
BusinessCategoryID
int
4
bcBusinessCategoryName
varchar
100
bcVisibleFlag
int
4
bcSortID
int
4
<b>20 - Структура</b>
tblBusinessCategoryFamily (Структура)
Столбец
Тип данных
Длина
BusinessCategoryID
int
4
mBusinessFamilyID
int
4
required
bit
1
RecordMapID
int
4
<b>21 - Структура</b>
tblBusinessSkills (Структура)
Столбец
Тип данных
Длина
BusinessSkillID
int
4
bskDescription
varchar
100
bskVisibleFlag
bit
1
bskSortID
int
4
<b>22 - Структура</b>
tblBusinessCategorySkill (Структура)
Столбец
Тип данных
Длина
bsmBusinessSkillID
int
4
bsmBusinessCategoryID
int
4
bsmSortld
int
4
CatMapSkillID
int
4
<b>23 - Структура</b>
tblSLAProvisionProfilehflaster (Структура)
Столбец
Тип данных
Длина
SLAProfileGUID
uniqueidentifier
16
PSLAUserGUID
uniqueidentifier
16
SLAProfileName
varchar
255
SLAProfileBusinessSectorID
int
4
SLAProfileBusinessArenaID
int
4
SLAProfileBusinessFamilyID
int
4
SLAJobTitle
varchar
50
SLAJobDescription
varchar
2500
rpmRecordDate
datetime
8
rpmCurrentStatusID
int
4
<b>24 - Структура</b>
tblSLAProvisionProfileMasterGFs (Структура)
Столбец
Тип данных
Длина
SLAGFRecord ID
int
4
SLAProfileGUID
uniqueidentifier
16
GeneralFunctionID
int
4
<b>25 - Структура</b>
tblSLAProvisionProfileMasterSkills (Структура)
Столбец
Тип данных
Длина
SLAProfileGUID
uniqueidentifier
16
rsSkill ID
int
4
rsSkillPriority
int
4
SLASkillRecord ID
int
4
<b>26 - Структура</b>
tblSLAProfileMapMaterial (Структура)
SLAProfileGUID
uniqueidentifier
16
MaterialMasterID
int
4
ProficiencyID
int
4
CertificationRequired
bit
1
Certification Desc
varchar
100
CertificationDate
datetime
8
<b>27 - Структура</b>
tblSLAClient (Структура)ilSLACIient (Структура)
Столбец
Тип данных
Длина
SLACIientID
uniqueidentifier
16
SLACIientName
varchar
100
SLACIientStatusID
int
4
vParentCompanyName
varchar
100
vBusinessEntityTypeiD
int
4
vFedldentity
varchar
50
vYearCorp
varchar
50
vDandBNumber
varchar
50
vDandBRating
varchar
50
vFTEmployees
int
4
vFT_W2_em ployees
int
4
vURL
varchar
100
vPhone
varchar
50
vFax
varchar
50
vDBECertification
varchar
50
vDBETypeld
int
4
vDBECertificateNumber
varchar
50
vDBECertifyingBody
varchar
50
vEDI
char
1
vEFT
char
1
vClientEmployees
int
4
vCountryID
int
4
vPriorYearRevenues
money
8
vClientCount
numeric
9
NetROI
percentage
4
<b>28 - Структура</b>
tblSLACIientContract (Структура)
Столбец
Тип данных
Длина
SLACIientID
uniqueidentifier
16
SLAContract
varchar
100
SLAContractStatusID
int
4
ContractRecordID
int
4
ContractStartDate
datetime
8
ContractEndDate
datetime
8
ContractPaymentTermID
int
4
ContractPenaltyTerms
bit
1
IncentiveTerms
bit
1
CountofSLAProvisionSvcs
numeric
9
ProvisionDetailRecordCount
numeric
9
SLACIientlndustryID
int
4
SLAContractTypeID
int
4
SLAContractSalesOrgID
int
4
SLAContractSalesUserID
uniqueidentifier
16
<b>29 - Структура</b>
tblSLACIientUser (Структура)
Столбец
Тип данных
Длина
SLACIientUserID
uniqueidentifier
16
SLACIientID
uniqueidentifier
16
UserNameLast
varchar
25
UserNameFirst
varchar
25
UserPhone
varchar
50
UserEmail
varchar
50
UserSysLogin
varchar
10
Position/Title
varchar
50
<b>30 - Структура</b>
tblSLAProvisionDetail (Структура)
Столбец
Тип данных
Длина
SLAContractRecordID
int
4
SLAProvisionID
uniqueidentifier
16
SLAProvisionTypeID
int
4
SLAProvisionLaborTypeID
int
4
SLAResponseTimeID
int
4
SLAProvisionDesc
varchar
5000
BillableProvision
bit
1
SLAProvisionCost
money
8
ExpectedProvisionFrequency
numeric
9
ProvisionRecordFriendlyName
varchar
100
SLANonProvisionPenaltyDesc
varchar
1000
SLANonProvisionPenalty
money
8
DispatchResponseTimeID
int
4
StatusID
int
4
<b>31 - Структура</b>
tblSLAProvisionMaterials (Структура)
Столбец
Тип данных
Длина
MaterialMasterID
int
4
SLAProvisionProvisionMaterialID
uniqueidentifier
16
SLAProvisionID
uniqueidentifier
16
WarrantyMaterial
bit
1
StockRecordID
uniqueidentifier
16
LockedtyCount
numeric
9
<b>32 - Структура</b>
tblSLAProfileMapProvision (Структура)
SLAProfileGUID
uniqueidentifier
16
SLAProvisionID
uniqueidentifier
16
DetailMatchSkills
bit
1
DetailMatchJobDesc
bit
2
SLAProfileMapProvisionID
uniqueidentifier
16
<b>33 - Структура</b>
tblSLAProvisionDetailMapLocation (Структура)
Столбец
Тип данных
Длина
SLAProvisionID
uniqueidentifier
16
LocationID
int
4
SLAProvisionLocationID
uniqueidentifier
16
<b>34 - Структура</b>
tblSLACIientPO (Структура)
Столбец
Тип данных
Длина
SLACIientPOID
uniqueidentifier
16
SLACIientPO
varchar
50
CreateDate
datetime
8
StartDate
datetime
8
EndDate
datetime
8
POVersion
numeric
9
POStatus
int
4
POMaxSpend
money
8
SLAContractRecordID
int
4
<b>35 - Структура</b>
tblSLACIientPOLinesServices (Структура)
Столбец
Тип данных
Длина
SLACIientPOID
uniqueidentifier
16
SLACIientPOIDLine
numeric
9
SLAProvisionID
uniqueidentifier
16
SLAProvisionShortDesc
varchar
50
SLAProvisionBiilingRate
money
8
SLANonProvisionPenalty
money
8
Services Record ID
uniqueidentifier
16
<b>36 - Структура</b>
tblSLACIientPOLinesMaterials (Структура)
Столбец
Тип данных
Длина
SLACIientPOID
uniqueidentifier
16
SLACIientPOIDLine
numeric
9
SLAProvisionProvisionMaterialID
uniqueidentifier
16
MaterialBillRate
money
8
MaterialsPORecordID
uniqueidentifier
16
<b>88 - Структура</b>
tblProvisionPeriods (Структура)
Столбец
Тип данных
Длина
SLAProvision Period Desc
varchar
30
S LAProvision Period ID
int
4
<b>88 - Данные</b>
tblProvisionPeriods (Данные)
SLAProvision Period Desc
SLAProvisionPeriodID
Weekday_08:00-18:00
1
Weekday_00:01-07:59
2
Weekday_18:01-24:00
3
Weekend_08:00-18:00
4
Weekend_00:01-07:59
5
Weekend_18:01-24:00
6
Holiday_08:00-18:00
7
Holidad_00:01-07:59
8
Holidad_18:01-24:00
9
<b>89 - Структура</b>
tblSLAProvisionExpenseTypes (Структура)
Столбец
Тип данных
Длина
SLAProvision ExpenseTypeID
int
4
SLAProvisionExpenseTypeDesc
varchar
50
<b>89 - Данные</b>
tblSLAProvisionExpenseTypes (Данные)
SLAProvisionExpenseTypeID
SLAProvisionExpenseTypeDesc
1
Parking/Toll
2
Auto Mileage
3
Hotel Room
4
Per Diem
<b>37 - Структура</b>
tblSLARFXMaster (Структура)
Столбец
Тип данных
Длина
SLA_RFx_ID
int
4
Originator_User_ID
int
4
RFX_Template_ID
int
4
Order_Status_ID
int
4
Client_Bid_ID
varchar
100
RFX_Administration_LocationID
numeric
9
CurrencyID
int
4
BudgetedExpenditure
money
8
Financial_Approval_Required
char
1
Non_Finanical_Approval_Required
char
1
DateCreated
datetime
8
<b>38 - Структура</b>
tblSLARFXLines (Структура)
Столбец
Тип данных
Длина
SLA_RFx_ID
int
4
SLA_RFx_Line_ID
int
4
SLAProfileGUID
uniqueidentifier
16
GEO_Code_Type_ID
int
4
Provision Desc
sql_variant
Provision Locations
sql_variant
Expected_Service_Calls
numeric
9
Labor_Service_Type
int
4
Max_Bill_Rate
money
8
Max_Resource_Submittals
numeric
9
Provision_Response_TTimen_ID
int
4
Provision_Response_Time_Desc
varchar
500
<b>39 - Структура</b>
tblSLARFXProvision Records (Структура)
Столбец
Тип данных
Длина
SLA_RFx_Line_ID
int
4
SLAProvisionID
uniqueidentifier
16
SLAProvisionProvisionMaterialID
uniqueidentifier
16
RFx_Provision_Record_ID
uniqueidentifier
16
<b>40 - Структура</b>
tblSLAProviderSecondary (Структура)
Столбец
Тип данных
Длина
SLASecondaryProviderID
int
4
vSPCompanyName
varchar
100
vParentCompanyName
varchar
100
RequestRowID
int
4
vPublic
char
1
vBusinessEntityTypeID
int
4
vFedldentity
varchar
50
vYearCorp
varchar
50
vDandBNumber
varchar
50
vDandBRating
varchar
50
vFTEmployees
int
4
vFT_W2_employees
int
4
vURL
varchar
100
vPhone
varchar
50
vFax
varchar
50
vEmail
varchar
50
vRFXEmail
varchar
50
vDBECertification
varchar
50
vDBETypeId
int
4
vDBECertificateNumber
varchar
50
vDBECertifyingBody
varchar
50
vSmallBusinessDesignationID
int
4
vEDI
char
1
vEFT
char
1
vClientEmployees
int
4
vContracted
char
1
vContractNumber
varchar
50
vContractDate
datetime
8
vStatusTypeID
int
4
vProfileFile
int
4
vCountryID
int
4
vApprovalStatusID
int
4
vCurrentStatusID
int
4
vAccountManagerl D
int
4
vExpirationDate
datetime
8
vJDPowerRatincj
varchar
50
vISOCertified
varchar
50
<b>41 - Структура</b>
tblSLAProviderSecondarYUser (Структура)
Столбец
Тип данных
Длина
SLASecondaryProviderID
int
4
SLASecondaryProviderUserID
uniqueidentifier
16
SLASecondaryProviderUserName
varchar
50
SLASecondaryProviderUserPhone
varchar
50
SLASecondaryProviderUserEmail
varchar
50
SLASecondaryProviderUserTypeID
int
4
SLASecondaryProviderUserStatusID
int
5
SLASecondaryProviderUserCreateDate
datetime
8
SLASecondaryProviderUserLogin
varchar
50
<b>42 - Структура</b>
tblSLAProviderWIapFamily (Структура)
Столбец
Тип данных
Длина
Record_MapID
int
4
vpSLAProviderID
int
4
vpFamilyID
int
4
vpApprovalStatus ID
int
4
vpCurrentStatusID
int
4
vpApprovedDate
datetime
4
vpCreateDate
datetime
4
<b>43 - Структура</b>
tblSLAProviderMapCountry (Структура)
Столбец
Тип данных
Длина
SLAProviderMapFamID
int
4
pcCountryID
int
4
pcFamilyID
int
4
pcApprovalStatusID
int
4
pcCurrentStatusID
int
4
pcSLAProviderID
int
4
pcCountryPartial
int
4
SLAProviderFamCountryID
int
4
<b>44 - Структура</b>
tblSLAProviderMapRegion (Структура)
Столбец
Тип данных
Длина
SLAProviderFamCountryID
int
4
prRegionID
int
4
prFamilyID
int
4
prApprovalStatusID
int
4
prCurrentStatusID
int
4
pcSLAProviderID
int
4
prReg ion Partial
int
4
SLAProviderpRegionID
int
4
<b>45 - Структура</b>
tblSLAProviderMapCounty (Структура)
Столбец
Тип данных
Длина
SLAProviderpRegionID
int
4
prRegionID
int
4
prFamilyID
int
4
prApprovalStatusID
int
4
prCurrentStatusID
int
4
pcSLAProviderID
int
4
prCountyPartial
int
4
SLAProviderpCountyID
int
4
<b>46 - Структура</b>
tblSLAProviderMapCity (Структура)
Столбец
Тип данных
Длина
SLAProviderpCountyID
int
4
pctCityID
int
4
prFamilyID
int
4
pctApprovalStatusID
int
4
pctCurrentStatusID
int
4
pcSLAProviderID
int
4
SLAProviderpCityID
int
4
<b>47 - Структура</b>
tblSLARFXPost (Структура)
Столбец
Тип данных
Длина
SLA_RFx_ID
int
4
SLASecondaryProviderID
int
4
Post_Date
datetime
8
Post_Version
numeric
9
Response_Open_Date
datetime
8
Response_Close_Date
datetime
8
Partial_Response_Enabled
bit
1
Post_Record_ID
uniqueidentifier
16
<b>48 - Структура</b>
tblSLARFXResponseMain (Структура)
Столбец
Тип данных
Длина
Row_id
int
4
Post Record ID
uniqueidentifier
16
SLA RFx ID
int
4
SLASecondaryProviderID
int
4
SLA_RFX_Resp_Status_ID
int
4
Date Created
datetime
8
Date Submitted
datetime
8
SLA_RFX_Resp_ID
uniqueidentifier
16
<b>49 - Структура</b>
tblSLARFXResponseDetail (Структура)
Столбец
Тип данных
Длина
SLAmRFX_Resp_ID
uniqueidentifier
16
SLA_RFx_Line_ID
int
4
SLAProfileGUID
uniqueidentifier
16
Provision_Response_Time_Acceptance
bit
1
Billing_Rate_Labor
sql_variant
Billing_Rate_Expenses
sql_variant
Provision_Quote_ID
uniqueidentifier
16
Bid Award Status
int
4
<b>50 - Структура</b>
tblSLARFXResponseSubmittal (Структура)
Столбец
Тип данных
Длина
SLA Submittal ID
uniqueidentifier
16
Provision Quote ID
uniqueidentifier
16
VendorContactID
int
4
VendorContactName
varchar
100
VendorContactPhone
varchar
100
VendorContactEmail
varchar
100
SLASubmittalStatusID
int
4
SubmittaIDate
datetime
8
ResourceFirstName
varchar
50
ResourceLastName
varchar
50
ResourceMiddleName
varchar
50
WorkLocationAcceptance
bit
1
Work Authorithaztion Desc
varchar
100
Social_Security^No
varchar
50
MilitaryGovClearance
char
1
MilitaryGovClearanceDescription
varchar
50
EmploymentAgreement
char
1
VendorNotes
varchar
1000
DeclinedReason
varchar
500
ResumePath
varchar
100
AvailableStartDate
datetime
8
PreviouslyWorked
char
1
DrugTested
char
1
DrugTestDescription
varchar
100
DrugTestDate
datetime
8
PeopleJD
uniqueidentifier
16
<b>51 - Структура</b>
tblSLASecondaryProviderPO (Структура)
Столбец
Тип данных
Длина
SLASecondaryProviderPOID
uniqueidentifier
16
PurchaseOrderldentifier
varchar
50
CreateDate
datetime
8
StartDate
datetime
8
End Date
datetime
8
POVersion
numeric
9
POStatus
int
4
POMaxSpend
money
8
ApprovalStatusID
int
4
SLA RFX Resp ID
uniqueidentifier
16
POReqID
uniqueidentifier
16
POReqNumber
varchar
20
SSPUserApprovalID
uniqueidentifier
16
PSPApproverID
uniqueidentifier
16
<b>52 - Структура</b>
tblSLASecondaryProviderPOLine (Структура)
Столбец
Тип данных
Длина
SLASecondaryProviderPOID
uniqueidentifier
16
Provision_Quote_ID
uniqueidentifier
16
SLAProfileGUID
uniqueidentifier
16
Billing_Rate_Labor
sql_variant
Billing_Rate_Expenses
sql_variant
SLAProvisionID
uniqueidentifier
16
SLASecondaryProviderPOLineID
uniqueidentifier
16
SLASecondaryProviderPOLine
numeric
9
SLAProvisionDesc
varchar
5000
SLAProvisionProvisionMaterialID
uniqueidentifier
16
SLAMaterialPrice
money
8
SLANonProvisionPenaltyDesc
varchar
1000
SLANonProvisionPenalty
money
8
POReqID
uniqueidentifier
16
POReqLineNumber
numeric
9
<b>90 - Структура</b>
tblBRProvisionPeriodBilling (Структура)
Столбец
Тип данных
Длина
SLA_RFX_Resp_ID
uniqueidentifier
16
SLA_RFx_Line_ID
int
4
SLAProvisionPeriodID
int
4
Billing_Rate
money
8
BillingRateID
uniqueidentifier
16
BillingRateBundleID
uniqueidentifier
16
SLASecondaryProviderUserID
uniqueidentifier
16
<b>91 - Структура</b>
tblBRExpenseBilling (Структура)
Столбец
Тип данных
Длина
SLA_RFX_Resp_ID
uniqueidentifier
16
SLA_RFx_Line_ID
int
4
SLAProvisionExpenseTypeID
int
4
Reimbursement_Requested
bit
1
Per_Occurrence_Max
money
8
ExpenseRateID
uniqueidentifier
16
ExpenseRateBundleID
uniqueidentifier
16
SLASecondaryProviderUserID
uniqueidentifier
16
<b>53 - Структура</b>
tblSLALaborer (Структура)
Столбец
Тип данных
Длина
PeopleJD
uniqueidentifier
16
LoginID
varchar
10
NDASys
bit
1
NDASysDate
datetime
8
NDASLAPP
bit
1
NDASLAPPDate
datetime
8
IPSLAPP
bit
1
IPSLAPPDate
datetime
8
ATWSLAPP
bit
1
ATWSLAPPDate
datetime
8
InfoValidation
int
4
InfoValidationDate
datetime
8
SLASPEmp
bit
1
SLASPEmpDate
datetime
8
CreateDate
datetime
8
SysAccessDate
datetime
8
LastAccessDate
datetime
8
StatusID
int
4
SLASPID
int
4
ActiveAssignment
bit
1
<b>54 - Структура</b>
tblSLAPOHRAssignment (Структура)
Столбец
Тип данных
Длина
SLASecondaryProviderPOLineID
uniqueidentifier
16
SLAProvisionID
uniqueidentifier
16
SLA Submittal ID
uniqueidentifier
16
PeopleJD
uniqueidentifier
16
StatusID
int
4
SLAPPApproverID
uniqueidentifier
16
SLAPPApprovedDate
datetime
8
AssignmentID
uniqueidentifier
16
SLASPConfimnDate
datetime
8
SLASPUserID
uniqueidentifier
16
<b>55 - Структура</b>
tblSLALaborScheduleMain (Структура)/iew)
Столбец
Тип данных
Длина
LaborPeopleID
uniqueidentifier
16
StdScheduleID
uniqueidentifier
16
StatusID
int
4
DateCreated
datetime
8
SLASPApproverID
uniqueidentifier
16
AssignmentID
uniqueidentifier
16
<b>56 - Структура</b>
tblSLALaborScheduleDefault (Структура)View)
Столбец
Тип данных
Длина
StdScheduleID
uniqueidentifier
16
DayNameID
int
4
BeginBlackOut
int
4
EndBlackOut
int
4
RecordID
uniqueidentifier
16
<b>57 - Структура</b>
tblSLALaborScheduleNondDefault (Структура)
Столбец
Тип данных
Длина
StdScheduleID
uniqueidentifier
16
DateID
int
4
BOEntryTypeID
int
4
BeginBlackOut
int
4
End BlackOut
int
4
NonstandardBORecordID
uniqueidentifier
16
DateCreated
datetime
8
StatusID
int
4
SLASPApproverID
uniqueidentifier
16
<b>58 - Структура</b>
tblDate (Структура)
Столбец
Тип данных
Длина
DateID
int
4
DayNumberID
int
4
DayNameID
int
4
MonthID
int
4
YearID
int
4
<b>59 - Структура</b>
tblDateDayName (Структура)
Столбец
Тип данных
Длина
DayNameID
int
4
DayNameDesc
varchar
10
<b>60 - Структура</b>
tblDateDayNumber (Структура)
Столбец
Тип данных
Длина
DayNameID
int
4
DayNameDesc
numeric
9
<b>61 - Структура</b>
tblDateMonth (Структура)
Столбец
Тип данных
Длина
MonthID
int
4
MonthDesc
varchar
10
<b>62 - Структура</b>
tblDateYear (Структура)
Столбец
Тип данных
Длина
YearID
int
4
YearDesc
numeric
9
<b>63 - Структура</b>
tblDateTime (Структура)
Столбец
Тип данных
Длина
GMTHalfHourID
int
4
GMTHourDesc
varchar
6
<b>64 - Структура</b>
tblSLAProvisionRequestMain (Структура)
Столбец
Тип данных
Длина
SLAProvisonRequestID
uniqueidentifier
16
SLACIientControlID
varchar
25
StatusID
int
4
CreateDate
datetime
8
SLACIientUserID
uniqueidentifier
16
SLAPPResponse
datetime
8
SLAPPUserID
uniqueidentifier
16
<b>65 - Структура</b>
tblSLAProvisionRequestSvc (Структура)
Столбец
Тип данных
Длина
SLAProvisonRequestID
uniqueidentifier
16
SLAProvisionID
uniqueidentifier
16
SLAProfileGUID
uniqueidentifier
16
SLAProvisionLaborTypeID
int
4
SLAResponseTimeID
int
4
SLAProvisionDesc
varchar
5000
SLACIientNotes
varchar
1000
ServiceLineID
uniqueidentifier
16
SLAProvisionLocationID
uniqueidentifier
16
Location_Details
varchar
500
MannedFacility
bit
1
LocationBadgingRequired
bit
1
GovtClearanceRequired
bit
1
LocationParkingDesc
varchar
500
LocationAccessDesc
varchar
500
LocationFreightDeliveryDesc
varchar
500
EmergencyAccessContactDetails
varchar
500
<b>66 - Структура</b>
tblSLAProvsionRequestMat (Структура)
Столбец
Тип данных
Длина
ServiceLineID
uniqueidentifier
16
SLAProvisionMaterialID
uniqueidentifier
16
MateriaIDesc
varchar
50
StockRecordID
uniqueidentifier
16
QtyRequired
numeric
9
MaterialLineID
uniqueidentifier
16
<b>67 - Структура</b>
tblSLAProvisionRequestStatus (Структура)
Столбец
Тип данных
Длина
ServiceRequestStatusID
int
4
ServiceRequestStatusDesc
varchar
20
<b>67 - Данные</b>
tblSLAProvisionRequestStatus (Данные)
ServiceRequestStatusID
ServiceRequestStatusDesc
1
Temporary_Save
2
New Submission
3
SLAPP_Acknowledged
4
SLAPP_Nonprocessed
5
Svc_Dispatch_Request
6
Dispatched
7
Awaiting_Voucher
8
Voucher_Pending
9
Voucher_Disposition
<b>68 - Структура</b>
tblSLAProvisionRequestDispatchMain (Структура)
Столбец
Тип данных
Длина
SLAProvisonRequestID
uniqueidentifier
16
ProvisionServiceLineID
uniqueidentifier
16
SLASecondaryProviderID
int
4
SLASecondaryProviderPOID
uniqueidentifier
16
SLASecondaryProviderPOLineID
uniqueidentifier
16
SLAResourceCapacity
bit
1
SLAResourceCapacityCount
numeric
9
QuerydDate
datetime
8
SLAPPUserID
uniqueidentifier
16
SLAProvisionCapacityID
uniqueidentifier
16
Billing_Rate_Labor
sql_variant
Billing_Rate_Expenses
sql_variant
SLA_Penalty
money
8
ResourceSelectionPreferenceID
int
4
SLASPDispatchRequestStatusID
int
4
<b>69 - Структура</b>
tblSLAProvisionRequestDispatchLabor (Структура)
Столбец
Тип данных
Длина
SLAProvisionCapacityID
uniqueidentifier
16
PeopleJD
uniqueidentifier
16
AssignmentID
uniqueidentifier
16
StdScheduleID
uniqueidentifier
16
Resource Available
bit
1
Provision Metrics
bit
1
ProvisionCapacityDetail
uniqueidentifier
16
SelectionStatusID
int
4
<b>70 - Структура</b>
tblSLAResourceDispatchPreference (Структура)
Столбец
Тип данных
Длина
ResourceSelectionPreferenceID
int
4
ResourceSelectionPreferenceDesc
varchar
50
<b>70 - Данные</b>
tblSLAResourceDispatchPreference (Данные)
ResourceSelectionPreferenceID
ResourceSelectionPreferenceDesc
1
Any_Available_Resource
2
Specific_Resource_Request
<b>71 - Структура</b>
tblSLADispatchRequestStatus (Структура)
Столбец
Тип данных
Длина
SLASPDispatchRequestStatusID
int
4
SLASPDispatchRequestStatusDesc
varchar
50
<b>71 - Данные</b>
tblSLADispatchRequestStatus (Данные)
ResourceSelectionPreferenceID
ResourceSelectionPreferenceDesc
1
Temporary_Save
2
New_Submission
3
SLASP_Acknowledged
4
SLA_Client_Notified
5
SLASP_Declined
5
Open
<b>72 - Структура</b>
tblSLAProvisionRequestDispatchDetails (Структура)
Столбец
Тип данных
Длина
SLASecondaryProviderID
int
4
SLAProvisionCapacityID
uniqueidentifier
16
SLAClientID
uniqueidentifier
16
SLAProvisionLocationID
uniqueidentifier
16
ResourceSelectionPreferenceID
int
4
AssignmentID
uniqueidentifier
16
SLAClientUserID
uniqueidentifier
16
SLAPPUserID
uniqueidentifier
16
SLAProvisionLaborTypeID
int
4
SLAResponseTimeID
int
4
Response_Deadline
datetime
8
SLAProvisionDesc
varchar
5000
SLAClientNotes
varchar
1000
SLASPUserID
uniqueidentifier
16
CreateDate
datetime
8
ServiceLineID
uniqueidentifier
16
SLAProvisionMaterialID
uniqueidentifier
16
StockRecordID
uniqueidentifier
16
SLASecondaryProviderPOID
uniqueidentifier
16
SLASecondaryProviderPOLineID
uniqueidentifier
16
SLASPAcknowledgeDate
datetime
8
ValidateDispatch
int
4
ResourceETA
datetime
8
<b>73 - Структура</b>
tblSLAVoucherMain (Структура)
Столбец
Тип данных
Длина
DispatchDetailID
uniqueidentifier
16
AssignmentID
uniqueidentifier
16
SLASP_DateCreated
datetime
8
Service_Date
datetime
8
LocationID
int
4
SLASecondaryProviderID
int
4
SLASecondaryProviderContact
uniqueidentifier
16
SLACIientControlID
varchar
25
SLASPVoucherID
uniqueidentifier
16
SLACIientID
uniqueidentifier
16
<b>74 - Структура</b>
tblSLAVoucherDetailSvc (Структура)
Столбец
Тип данных
Длина
SLASPVoucherID
uniqueidentifier
16
SLASecondaryProviderPOID
uniqueidentifier
16
SLASecondaryProviderPOLineID
uniqueidentifier
16
SLAProvisionID
uniqueidentifier
16
SLAProvisionVoucherDesc
varchar
1000
ProvisionDateID
int
4
Arrive_Time
datetime
8
Depart_Time
datetime
8
ProvisionRequestTime
datetime
8
Labor_Time
numeric
9
SLAProvisionLaborTypeID
int
4
Labor_Qty
numeric
9
SP_Labor_Charge
money
8
SLAVoucherSvcLineID
uniqueidentifier
16
ProvisionOutcomeStatus
int
4
SLASPResponsePenaltyStatus
int
4
SLAPPReviewerID
uniqueidentifier
16
SLAPPReviewerDate
datetime
8
SLAPPReviewerStatusID
int
4
SLAPPReviewerNotes
varchar
1000
ServicesRecordID
uniqueidentifier
16
Billable_Provision
bit
1
SLACIientPOIDLine
numeric
9
SLAProvisionBillingRate
money
8
SLANonProvisionPenalty
money
8
SLACIientReviewerID
uniqueidentifier
16
SLACIientPReviewerDate
datetime
8
SLACIientReviewerStatusID
int
4
SLACIientReviewerNotes
varchar
1000
Provision_Performance_ID
int
4
Logistical_Administration_ID
int
4
<b>75 - Структура</b>
tblSLAVoucherDetailMat (Структура)
Столбец
Тип данных
Длина
SLASPVoucherID
uniqueidentifier
16
SLASecondaryProviderPOID
uniqueidentifier
16
SLASecondaryProviderPOLineID
uniqueidentifier
16
SLAProvisionID
uniqueidentifier
16
SLAProvisionProvisionMaterialID
uniqueidentifier
16
Provision_Material_Cost
money
8
Provision_Qty
numeric
9
SLAVoucherSvcLineID
uniqueidentifier
16
SLAVoucherMatLineID
uniqueidentifier
16
SLAPPReviewerID
uniqueidentifier
16
SLAPPReviewerDate
datetime
8
SLAPPReviewerStatusl D
int
4
SLAPPReviewerNotes
varchar
1000
MaterialsPORecordID
uniqueidentifier
16
Billable_Provision
bit
1
SLACIientPOIDLine
numeric
9
MaterialBillRate
money
8
Total_Charge
money
8
SLACIientReviewerID
uniqueidentifier
16
SLACIientPReviewerDate
datetime
8
SLACIientReviewerStatusID
int
4
SLACIientReviewerNotes
varchar
1000
<b>76 - Структура</b>
tblSLAVoucherProvisionOutcomeStatus (Структура)
Столбец
Тип данных
Длина
ProvisionOutcomeStatusID
int
4
ProvisionOutcomeStatusDesc
varchar
50
<b>76 - Данные</b>
tblSLAVoucherProvisionOutcomeStstus (Данные)
ProvisionOutcomeStatusID
ProvisionOutcomeStatusDesc
1
Provision_Complete
2
No_Provision_Needed
3
Provision_Incomplete_Need_Troubleshooting
4
Provision_Incomplete_Need_Parts
5
Provision_Incomplete_Out_Of_Scope_Provision
<b>77 - Структура</b>
tblSLAVoucherStatus (Структура)
Столбец
Тип данных
Длина
VoucherStatusID
int
4
VoucherStatusDesc
varchar
25
<b>77 - Данные</b>
tblSLAVoucherStatus (Данные)
VoucherStatusID
VoucherStatusDesc
1
Submitted_To_SLAPP
2
Submitted To SLACIient
3
Approved
4
Declined SLACIient
5
Declined_SLAPP
6
On Hold
7
Contested SLAPP
8
Contested_SLACIient
9
Contested_Declination_SP
<b>78 - Структура</b>
tblSLAVoucherProvisionPerformance (Структура)
Столбец
Тип данных
Длина
Provision_Performance_ID
int
4
Provision_Performance_Desc
varchar
50
<b>78 - Данные</b>
tblSLAVoucherProvision Performance (Данные)
Provision_Performance_ID
Provision Performance_Desc
1
Poor
2
Fair
3
Good
4
Excellent
5
Outstanding
<b>79 - Структура</b>
tblSLAVoucherLogisticPerformance (Структура)
Столбец
Тип данных
Длина
Logistical_Admin_ID
int
4
Logistical_Admin_Desc
varchar
50
<b>79 - Данные</b>
tblSLAVoucherLogisticPerformance (Данные)
Provision Performance ID
Provision_Performance_Desc
1
Poor
2
Fair
3
Good
4
Excellent
5
Outstanding
<b>80 - Структура</b>
tblSLAVoucherDecinationCodes (Структура)
Столбец
Тип данных
Длина
Decline_Code ID
int
4
Decline Code Desc
varchar
50
<b>80 - Данные</b>
tblSLAVoucherDecinationCodes (Данные)
Provision_Performance_ID
Provision_Performance_Desc
1
Incorrect_PO_Data
2
Incorrect_Provision_Data
3
Service_Provision_Failure
<b>81 - Структура</b>
tblSLAVoucherDecinationDetails (Структура)
Столбец
Тип данных
Длина
SLAVoucherSvcLineID
uniqueidentifier
16
Decline_Code_ID
int
4
SLACIientReviewerID
uniqueidentifier
16
Declination_Commentary
varchar
1000
<b>82 - Структура</b>
tblSLAVoucherExtractMain (Структура)
Столбец
Тип данных
Длина
VoucherExtractBatchID
uniqueidentifier
16
ExtractDateStart
datetime
8
ExtractDateStartFinish
datetime
8
ExtractRecordCount
numeric
9
FieldExtractID
int
4
ExtractStatusID
int
4
<b>83 - Структура</b>
tblSLAVoucherExtractRecords (Структура)
Столбец
Тип данных
Длина
SLASPVoucherID
uniqueidentifier
16
SLAVoucherSvcLineID
uniqueidentifier
16
SLAVoucherMatLineID
uniqueidentifier
16
SLASPResponsePenaltyStatus
int
4
ApprovalDate
datetime
8
ExtractRecordID
uniqueidentifier
16
VoucherExtractBatchID
uniqueidentifier
16
<b>84 - Структура</b>
tblSLAInvoiceClientMain (Структура)
Столбец
Тип данных
Длина
VoucherExtractBatchID
uniqueidentifier
16
ClientlnvoiceFileID
uniqueidentifier
16
SLACIientID
uniqueidentifier
16
InvoiceFileStatusID
int
4
<b>85 - Структура</b>
tblSLAInvoiceClientDetail (Структура)
Столбец
Тип данных
Длина
ExtractRecordID
uniqueidentifier
16
WarrantyWork
bit
1
Debit
bit
1
Credit
bit
1
SLACIientName
varchar
100
SLAContract
varchar
100
SLACIientPO
varchar
50
SLACIientPOiDLine
numeric
9
SLAProvisionID
uniqueidentifier
16
ProvisionLocationName
varchar
50
SLAProvisionLaborTypeDesc
varchar
50
Labor_Qty
numeric
9
SLAProvisionBillingRate
money
8
SLAProvisionLaborCharge
money
8
MaterialMasterShortName
varchar
50
Provision Material Cost
money
8
Provision_Qty
numeric
9
SLAProvisionMaterialCharge
money
8
ProvisionDate
smalldate
8
SLACIientApprovaIDate
smalldate
8
SLACIientApprover
varchar
100
SLANonProvisionPenaltyDesc
varchar
1000
SLANonProvisionPenalty
money
8
ClientlnvoiceLineID
uniqueidentifier
16
ClientlnvoiceFileID
uniqueidentifier
16
CashReceiptsControl
varchar
50
CashReceiptsDate
datetime
8
CashReceiptsAmount
money
8
CashPaymentsControl
varchar
50
CashPaymentsDate
datetime
8
CashPaymentsAmount
money
8
<b>86 - Структура</b>
tblSLAInvoiceSPMain (Структура)
Столбец
Тип данных
Длина
VoucherExtractBatchID
uniqueidentifier
16
SPInvoiceFileID
uniqueidentifier
16
SLASecondaryProviderID
int
4
InvoiceFileStatusID
int
4
<b>87 - Структура</b>
tblSLAInvoiceSPDetail (Структура)
Столбец
Тип данных
Длина
ExtractRecordID
uniqueidentifier
16
Debit
bit
1
Credit
bit
1
vSPCompanyName
varchar
100
SLASecondaryProviderPOID
uniqueidentifier
16
PurchaseOrderldentifier
varchar
50
SLASecondaryProviderPOLine
numeric
9
SLAProvisionID
uniqueidentifier
16
ProvisionLocationName
varchar
50
SLAProvisionLaborTypeDesc
varchar
50
Labor_Qty
numeric
9
Billing_Rate_Labor
money
8
SLASPProvisionLaborCharge
money
8
MaterialMasterShortName
varchar
50
SLAMaterialPrice
money
8
Provision_Qty
numeric
9
SLASPProvisionMaterialCharge
money
8
ProvisionDate
smalldate
8
SLACIientApprovaIDate
smalldate
8
SLACIientApprover
varchar
100
SLASPNonProvisionPenaltyDesc
varchar
1000
SLASPNonProvisionPenalty
money
8
SLASPInvoiceLineID
uniqueidentifier
16
SPInvoiceLineID
uniqueidentifier
16
CashPaymentsControl
varchar
50
CashPaymentsDate
datetime
8
CashPaymentsAmount
money
8
CashReceiptsControl
varchar
50
CashReceiptsDate
datetime
8
CashReceiptsAmount
money
8
Предыдущее подробное описание содержит вариант(ы) воплощения изобретения. Объем изобретения не обязательно должен быть ограничен в соответствии с этим описанием. Вместо этого объем изобретения определен следующей формулой изобретения или ее эквивалентами.