CN_EN_4

 

 

 

 

CRM系統設備與建置專案」

建議書徵求說明書

 

 

 

 

 

國碁電子股份有限公司

中華民國103年01月02日

 

 

 

 

1.   專案說明

     為滿足國碁電子4G通訊服務開台營運策略,進行Customer Relationship Management(CRM)系統公開徵求資訊解決方案建議書,期運用系統方式並加以改善減少人工謬誤、節省時間及紙本耗用,整合其他系統增進各項業務效能。

1.1. 專案目標

本專案名稱為「CRM系統建置規劃及維護專案」其目標,建立電子化系統透過整合帳務系統、營運系統及資料庫之間應用程式,有效分析與管理系統,以下簡稱專案。

1.2. 專案連絡窗口

  • 主要連絡窗口:

連絡人:國碁電子資訊總處莊英池

地址:11492台北市內湖區基湖路32號2樓

連絡電話:(02)7733-0566 分機 12726

傳真號碼:(02)7745-0927

e-mail:matthew.yc.chuang@ambit.com.tw

 

  • 支援連絡窗口:

連絡人:國碁電子營運系統處張國偉

地址:11492台北市內湖區基湖路32號2樓

連絡電話:(02)7733-0566 分機 12725

傳真號碼:(02)7745-0927

e-mail:stephen.kw.chang@ambit.com.tw

 

  • 廠商報價窗口:

連絡人:國碁電子資訊總處楊道天 副總經理

地址:11492台北市內湖區基湖路32號2號

連絡電話:(02)7733-0566 分機 12707

傳真號碼:(02)7745-0927

e-mail:sky.dt.yang@ambit.com.tw

除非本公司另行建議,否則不能向上述窗口以外之任何人員,就本《建議書徵求說明書》進行聯繫或接洽。

1.3. 建議書截止期限

國碁電子訂立以下時間表旨在獲取最優化資訊,故有權視業務需要調整相關安排,所有回覆必須在2014年1月23日前送達。

項目 完成日期
發出《建議書徵求說明書》 2014年1月2日
回覆《建議書徵求說明書》期限 2014年1月23日
《建議書》簡報 2014年2月19日前

 

1.4. 履約條款

以下條款是廠商回覆本《建議書徵求說明書》必須嚴格遵守的要求。如果廠商違反以下條款,將被視為喪失資格。

1.4.1.           國碁電子有權就廠商提供的回覆要求獲得額外的書面或口頭資料。

1.4.2.           廠商必須在以上截止期限前回覆國碁電子,任何延遲視為喪失資格。

1.4.3.           廠商選擇以其提供《建議書》是否符合國碁電子業務運作需要為主要依據,非僅以價格的高低定論。

1.4.4.           國碁電子在本專案執行之前保留修改本《建議書徵求說明書》中具體內容的權利,其中包括將合約拆分後授予不同廠商的權利。

1.4.5.           除非國碁電子特別通知,所有與本《建議書徵求說明書》相關的問題必須透過書面的形式提出(包括電子郵件)。

1.4.6.           當國碁電子需要進一步瞭解某廠商的某一問題,而該廠商又解釋不清的情況下,國碁電子可向其他廠商(可不通知該廠商)徵求答案。

1.4.7.           每位廠商須於期限內交付五份《建議書》書面文件,同時將一份電子版本透過電子郵件方式寄予上述連絡窗口。所有電子檔案須以文書套裝軟體(如MSWord)製作,若檔案容量較大,可以光碟形式存放。

1.4.8.           廠商提供的產品介紹彩頁應該獨立寄送,並附內容清單以便閱讀。

1.4.9.           廠商若邀請其他廠商共同參與本專案,需在所提交《建議書》中載明合作廠商相關資料及分工方式,如未經國碁電子事先同意,不得委託第三人執行;有關承包本專案之所有責任應由投標廠商全部承擔,廠商亦為得標時本公司簽約之唯一對象。

1.5. 保密條款

廠商必須將從本《建議書徵求說明書》獲悉之資料及其後與國碁電子聯繫獲悉之其他資料視為機密資料。其相關保密約定事項以雙方簽訂之【保密同意書】為依據。

1.6. 聲明

廠商必須就國碁電子提供之資料進行方案評估,國碁電子就此提供之相關資料僅供參考,實際資料以實際業務量為準。

1.7. 成本與廠商選擇

1.7.1.           廠商向國碁電子準備《建議書》、提供額外資訊和進行簡報等簽約前所需費用,均由廠商自行負擔。

1.7.2.           本《建議書徵求說明書》發出後,並非意味著國碁電子必須接受其中回覆的任何一份《建議書》。國碁電子亦不保證一定會與任何一家或多家廠商簽約。為了符合國碁電子的最佳效益,《建議書》中若有不合規範或不正式的內容,將於審核時忽略之。在上述情況下,國碁電子可能要求廠商稍微修改《建議書》之內容(與價格有關的內容除外)。

1.7.3.           國碁電子收到《建議書》後,將進行初步審核,通過審核之廠商,須就《建議書》內容進行簡報,簡報將在國碁電子指定地點進行,簡報相關費用由廠商自行負擔,國碁電子有權依照廠商所提供《建議書》決定至本公司進行簡報之廠商,未參與廠商不得有任何異議。

國碁電子有可能透過與廠商的客戶聯繫,瞭解廠商客戶對廠商產品和服務的滿意程度。廠商必須參考客戶資料,其中應該包括工作性質與電信相關的客戶。

 

 

2.   需求說明

本系統功能需求如下所述,惟實際功能需求內容則以得標廠商於系統分析階段與USER部門進一步確認之結果為依據。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.6. 客戶訂單業務受理

客戶訂單業務受理,主要處理AP form的作業流程,包括客戶訂單建立、審核、確認及發送、異常處理等功能,從而實現端到端的全業務、全管道的訂單業務受理處理。此外,訂單業務受理處理是客戶管理系統的核心功能模組,要具有高度的靈活性、穩定性和擴展性。業務受理處理要能夠支援根據業務要求靈活定制流程,同時要使業務受理處理的流程統一性。

2.6.1.1.          支持包括各種業務申裝/異動/取消資訊、產品申裝/異動/取消資訊等訂單業務受理。

2.6.1.2.          業務受理的管道,可借由FAX、eMail、Web、APP、店點等不同管道而來,並需整合影像檔管理系統,做為進件人員輸入訂單時的附件處理。

2.6.1.3.          業務受理作業執行各項服務申裝異動的作業的依據,例如:基本與加值服務的新申裝與異動,變更上網資費,自停/自復、欠停/欠復等作業。

2.6.1.4.          業務受理變更。一個業務受理單可以在未完成之前被變更(可設定業務受理單在什麼階段可以進行更改的既定業務規則)。可能更改的業務受理單資訊包括資費檔次、聯繫電話等。

2.6.1.5.          業務受理單中記錄服務/產品的相關資訊,其中與服務開通相關的資訊應該傳送到OSS系統(Provisioning and Activation systems)用於開通服務等。

2.6.1.6.          提供便利簡單的操作步驟以完成訂單新增與更新,例如客戶一次購買大量服務或同時對大量服務做服務/產品變更。

2.6.1.7.          申裝流程需提供以下系統功能

n   查詢客戶資料:查詢客戶資料是否已存在

n   申裝檢核:輸入客戶證號,檢查黑名單。

n   輸入申請書資料:包含地址、聯絡人、經銷店點代碼,專案、資費、加選服務、裝置等資訊,及檢視系統所示各項費用收費。

n   供裝中狀態查詢:包含進單日、工單進度、或異常狀態等資訊。

n   查詢申裝結果:帳務立帳及開通作業成功後,可於系統查詢客戶相關資料,包含客戶、帳戶、用戶生效的狀態及安裝的資產。

2.6.1.8.          業務受理單新增及配置時,允許選購不同的促銷活動,包含跨產品間的折扣和不同產品間的捆綁。

2.6.1.9.          申裝時檢查業務受理單必需資訊的完整性和準確性:

n   檢查客戶的帳戶是否存在。

n   滿足這個業務受理單需要的各種產品定義是否完整,是否有相關的促銷方案等。

n   根據產品間的依賴關係,分析出滿足業務受理單所需的額外的必須的其他服務。例如:客戶需要多媒體服務,但他必須先有上網服務。如果必須的產品不存在,就需提醒進件處理人員或將錯誤資訊送到相關系統。

2.6.1.10.       客戶申請服務的一次性費用的付費方式應記錄在業務受理單中。此費用可根據需求與後台計費帳務系統整合或通知財務部門。

2.6.1.11.       客戶於新申裝後超過取消合約期限內,前來申請退租。系統提供之中止合約功能:

n   查詢客戶資料:查詢客戶資料是否已存在。

n   輸入退租申請書:選擇客戶退租原因,及檢核已出帳未繳款及違約金金額。

n   檢核退租結果:帳務及開通系統拆機作業成功後,可於客服系統查詢客戶相關資料,包含客戶、帳戶、用戶失效的狀態及安裝的資產移除。

2.6.1.12.       基本與加值服務異動時, 系統可自動檢核新申裝使用的服務和已使用中的服務是否有關聯或互斥, 提供前台人員即時的資訊, 並使後台開通作業可順利完成。

2.6.1.13.       可針對產品中的特定服務進行異動或退租。

2.6.1.14.       異動服務需求可能會涉及到合約,在進行變更之前,能夠確認當前合約的狀態並確認針對此異動是否有限制,如:所需的使用的最短期限、提前終止的罰金等,並在異動時能直接警示使用者或用戶。

2.6.1.15.       提供提前續約或延展合約的管理, 包含彈性的罰金計算:

n   提供提前續約及延展合約流程

n   如續約後, 下一個合約未生效前, 又解約, 要支付第一張合約和第二張合約的罰金

n   如鑑賞期一星期內, 不收費, 一星期後沒有退租, 則全部都有收費

2.6.1.16.       提供合約到期警示訊息; 可設定到期前什麼時後通知, 經由什麼管道通知, 通知訊息, 通知對象等。

2.6.1.17.       支援業務受理單取消。取消動作可以由人工提出,也可以接受由其他作業系統按業務規則進行。業務受理單取消功能還要將這個業務受理單相關的所有已經運行的動作全部取消(恢復初始狀態)。系統需紀錄取消業務受理單的原因

2.6.1.18.       能夠為使用者提供立即可用的使用者介面,以便掌握訂單。這個使用者介面涵蓋但不侷限於產品目錄、產品選擇、產品比較、產品屬性、向上銷售與交叉銷售訊息、價格提示、報價組合等。

2.6.1.19.       能夠在一個視窗中顯示所有相關的客戶資料、所購買的資產資料、計費資料與優惠推薦,以便執行附帶銷售/交叉銷售。

2.6.1.20.       能夠提供導引腳本,幫助工作人員提供產品/服務建議。

2.6.1.21.       能夠處理行銷活動、客戶服務或個案衍生的大量訂單。

2.6.1.22.       能夠在工作流程中提供完整的訂單生命週期管理,從客戶概要、業務訂單受理與提交訂單給後端系統。

2.6.1.23.       能夠創建訂單,以改變資費計畫 (向上/向下銷售)。

2.6.1.24.       能夠創建訂單,以新增/移除選項 (交叉銷售,例如搭配增值業務) 。

2.6.1.25.       能夠創建訂單,以修訂指派給產品的計費帳戶。

2.6.1.26.       能夠處理定義訂單的交貨明細,以便正確地將產品與服務交貨給客戶。

2.6.1.27.       提供產生因應在B2B與B2C環境中大批採購或行銷促銷所導致的大量訂單的能力。

2.6.1.28.       能夠產生預先填入部份訂單表格,含客戶資料與之前取得的資料。

2.6.1.29.       因應不同的訂單類型而提供立即可用的訂單介面與訂單處理流程。

2.6.1.30.       能夠跟蹤未來訂單。

2.6.1.31.       提供單一的客戶訂單業務受理系統,依據不同的店點類型,提供不同的輸入畫面,以便於店點業務受理的處理。

2.6.1.32.       與號碼管理系統整合,在訂單受理時方便客戶挑選行動電話號碼。

2.6.1.33.       能夠在服務啟用後,允許更新客戶概要資料。

2.6.1.34.       當用戶在合約期間內決定中斷服務時能夠啟動罰則,而且能夠依據完全付款、折扣付款或按照比例定義罰則。

2.6.1.35.       能夠紀錄訂單變更的歷史

2.7. 店點管理

店點包含直營店、加盟店及其他通路等不同類型通路,提供不同店點型態,包含客戶資訊查詢、申裝異動處理、客戶服務中心、帳務相關問題處理等作業,需求功能說明如下:

2.7.1.           建立店點代碼,並建立相關店點資訊,如店點地址、通路類型、公司統編、業務人員等。

2.7.2.           客戶申裝進件時,可依據業務受理單所記錄的店點代碼或業務人員編號,記錄於系統中,以便於後續統計報表分析之用。

2.7.3.           門號申請、分級、調撥、銷售與回收之管理。

2.7.4.           依店點手動或自動門號動態分配、獲取、保留與使用門號之系統與管理。

2.7.5.           銷售專案、加值、APP、雲端產品的上下架管理。

2.7.6.           支援傳統/電子無紙化作業、黑名單管理、資費專案選取、申裝、異動、查詢、退租作業。

2.7.7.           門市專業知識、問題題庫及輔助銷售系統與資費、專案與各式手機使用說明。

2.7.8.           提供最適資費試算。

2.7.9.           客訴作業轉送、跟催與結案回覆管理,並且客戶也能在本公司提供的客戶自助式服務的網站中找到相關資訊。

2.7.10.       直營店其他功能需求

2.7.10.1.       利用門市Kiosk或Pad,提供客戶在前往門市時,查詢各手機最新資訊、週邊配備、可取貨門市、行動上網、家用寛頻、國際漫遊等各服務的資費方案,藉此減低門市人員的負荷,也可以讓客戶臨櫃服務前,取得必要的資訊,以提升服務的品質並增加客戶滿意度。

2.7.10.2.       帳單繳費處理作業

2.7.11.       權限管理

2.7.11.1.       各店點只能查詢到自己店點所屬的資料

2.7.11.2.       授權相關系統功能,如申裝作業、繳費作業、客戶需求等

2.7.11.3.       可定義不同的通路類型及店點能查詢到哪些資料欄位

2.7.12.       報表需求:各店點銷售報告,包含總銷售額、依產品銷售額、新增客戶數、客戶案件提交等

2.8. 門號可攜

2.8.1.           建置內部集中式資料庫(LNPDB)及服務管理系統(LSMS)

2.8.1.1.          需確實了解「號碼可攜服務管理辦法」條文及NCC或相關電信法規之規定據以規劃符合國碁電子使用之攜碼用戶資料庫。

n   需確保攜碼用戶資料庫之資料正確性、安全性及正常運作功能。

n   需確保攜碼用戶資料交換所需設備與功能之正常運作。

n   需建立完整之資料備份及備援措施。

n   需建立並保留六個月以上之資料異動歷史紀錄檔案。

n   需建立雙重之攜碼用戶資料庫設備(包括資料庫系統、資料內容及資料庫伺服器均應至少兩套)

n   為建立正確的通信路由,須同步交換端攜碼用戶資料庫。

2.8.1.2.          LSMS應負責處理和CNPDB間交換之訊息類型如下:

n   攜碼服務申請程序之訊息

n   攜碼門號退租程序之訊息

n   更新資料程序之訊息

n   資料庫查核程序之訊息

n   資料庫修復程序之訊息

2.8.1.3.          LSMS資料交換之時機、格式、內容和通訊協定(protocol)等皆需符合集中式資料庫管理委員會或電總所制定之規範,應含:

n   接獲NPAC通報後之攜碼用戶資料庫更新時限。

n   檢視攜碼用戶資料庫資料正確性及資料更新之途徑及作業方式。

n   資料交換之介面規格、資料格式與程序及測試方法。

2.8.1.4.          內部集中式資料庫之相關要求如下:

n   當移入業者對已完成移轉作業之號碼,進行相關資訊的修改,其LNPDB資料庫更新時間:40分鐘。

n   當使用者或合約業者查覺網路設定有問題,造成使用者無法正常收發話時,合約業者可主動要求NPAC對全部或特定業者進行資料庫之查核動作,LNPDB資料庫內部查核的時間:最短20分鐘,最長2小時。

n   當因不可抗拒之因素,導致LNPDB的資料毀壞時,可以請求NPAC幫忙重新建立自己的LNPDB,其資料庫重建的時間:4小時。

n   當LNPDB更新失敗時,NPAC重送更新要求的次數:3次。

2.8.1.5.          需與CRM/Billing整合,以減少系統建置成本。

2.8.1.6.          其他相關需求如下:

n   集中式資料庫開始運作前,應配合已建置攜碼用戶資料庫之其他經營者及第二類電信事業進行攜碼用戶資料庫之資料交換測試。

n   集中式資料庫開始運作前,應於收到移入通報後一小時內,更新攜碼用戶資料庫並完成其他必要之路由資訊設定。

n   集中式資料庫開始運作前,應於收到終止通報後十二小時內,更新攜碼用戶資料庫並完成其他必要之路由資訊設定。

2.8.2.           建置號碼可攜服務之行政作業系統(SOA)

2.8.2.1.          需將應用軟體程式所產生之號碼可攜服務異動記錄轉換成訊息交換所需之標準格式及內容,並傳送給CNPDB或其他相關業者。

2.8.2.2.          需接收由CNPDB或其他相關業者傳來之號碼可攜相關訊息,並轉換成應用軟體程式可處理之格式內容。

2.8.2.3.          應交換之訊息類型應含:

n   攜碼服務申請程序之訊息

n   攜碼門號退租程序之訊息

n   取消程序之訊息

n   修改程序之訊息

n   爭議處理程序之訊息

n   更新資料程序之訊息

n   資料庫查核程序之訊息

2.8.2.4.          訊息交換之時機、格式、內容和通訊協定(protocol)皆需符合集中式資料庫管理委員會(NPAC)所制定之規範,其相關要求規定如下:

n   移出業者須回覆移入業者移轉申請的時間:收到移入業者申請資料後的第2個完整工作日結束之前。

n   移入業者向移出業者提出申請到合約生效日之間的時間:移入業者至少在合約生效日前的5個完整工作日之前提出。

n   合約生效日到所有資料庫完成更新的時間:1.5小時。

n   門號退租後,號碼歸還至原獲核配號碼業者的時間:話務終止日起7個完整工作日內。

n   話務終止日到所有資料庫完成更新的時間:1.5小時。

n   移入業者與移出業者協商取消申請的時間:1天,但不得超過上述第2.2項結束之時間。

n   移入業者與移出業者協商修改申請的時間:1天,但不得超過上述第2.2項結束之時間。

n   當移入業者對已完成移轉作業之號碼,進行相關資訊的修改,其更新資料庫的時間:1.5小時。

n   當使用者或合約業者查覺網路設定有問題,造成使用者無法正常收發話時,合約業者可主動要求NPAC對全部或特定業者進行資料庫之查核動作,其資料庫進行查核程序的時間:最短1.5小時,最長6小時。

2.8.2.5.          本訊息交換機制應能以自動及人工兩種操作模式運行。

2.8.2.6.          訊息之交換皆需保留歷史記錄以供查詢或報表之所需。

2.8.2.7.          可以依不同的業者別(如:TWM 3G或FET3G)而分別處理相關訊息。

2.8.2.8.          提供攜碼用戶資料交換進度查詢介面。

2.9. 服務開通

2.9.1.           工單管理(服務與訂單管理 Order and Service Management)

本系統將結合TM_Forum中ETOM與SID模型之概念規劃新的服務與訂單管理系統架構,面對市場變化、適應全業務融合、支撐複雜多樣化和快速共用的開通、異動需求。從而建立以下的支援能力:

從開發系統框架上看,要求新的工單系統符合TMF框架之要求,符合AMBIT之業務發展規劃。

2.9.1.1.          從業務面上來看,針對行網、固網、WIFI等多種工單的產品種類進行統合,要求新的工單系統能夠支援多種產品和bundle的組合。

2.9.1.2.          從流程上看,要求新的工單系統將不僅包含業務較單純的流程,還要支撐前後貫通的複雜流程,涉及自動工單站和人工工單站並存,複雜多工單站異常控制等重點業務場景。

2.9.1.3.          從業務開通相關的資源方面看,新的工單系統能處理業務平臺、核心網路、接入網路、以及合作夥伴的資源…等,複雜的資源需求。

2.9.2.           系統工作項目

2.9.2.1.          工單設計模組(Service Order)

工單設計涵蓋開通設計階段依據產品需求建立工單、業務邏輯、工單範本、操作人員角色的設計過程,並根據前後台協商制定協議完成開通相關的指標分解,並根據要求設置流程範本的整體和各工單站指標。

n   須提供圖形化的設計工具提供流程和使用者介面定制:工單站 (人工站,自動站,規則/邏輯判斷,延遲,平行站);分支,合併,跳轉和並行處理。業務設計流程中提供可重複使用流程(reuse)、子流程機制

n   須提供正常/異常流程管理:智慧判斷還原功能,異常流程處理配置 (in flight change)

n   須提供工作群組管理功能包括工作群組權限,工作時間、假期 (非工作日) ,分配方式能夠配置各項工單的角色及其權限

n   須提供時間管理功能包括工作日管理,工作時間管理,工單站時間管理,流程時間管理,工單時間管理和計畫啟動配置功能

n   須提供依據規則的提醒和監控功能如時間觸發,工單站觸發,事件觸發監控與發送提醒簡訊

n   須提供工單站管理功能包括各種工作站(Tasks),人員角色(Role),工作站資料介面,工作站異常等配置能力

n   須提供統一的規則管理(rule task):等待/事件觸發/資料觸發/使用者定制條件

n   須提供統一安全配置包括介面控制,安全認證

n   須包含支援設計範本的版本管理,一個服務開通設計範本包括資料元、流程、工單站、工作群組、業務邏輯、介面控制等,必須以XML的形式進行保存。系統能支援多版本的並行

n   針對SLA (Service Level Agreement)、產品、地區、客戶的個別需求,支援時間、流程(或分支流程)、客戶優先順序等須具有針對性的開通設計階段和功能。

n   依據地域不同選擇不同系統或業務資源

n   依據客戶等級不同選擇不同支援工作群組

n   依據客戶等級不同自動站應提供優先處理,人工站應以不同顏色標識

n   依據客戶、產品資料不同可設置不同時間提醒操作人員

2.9.2.2.          提供對各種狀態工單進行查看和處理的能力,包括:

n   查看工單流程歷史、查看通知歷史、取消工單、暫停工單、恢復工單、複製工單、修改工單、發出異常警告等等。

n   提供的多組合查詢能力,可定義系統中的任何資料欄位作為查詢條件,例如以客戶姓名、地址區域、工單狀態、工單站狀態等進行單項或組合查詢,並提供查詢保存功能。

2.9.3.           資料範本設計模組 (data template design)

資料元(data element)是開通系統中重要的傳遞元素,資料元不同的組合呈現出不同的業務工單。因此資料範本設計是衡量開通系統設計便利性快速應對市場需求(TTM, Time to Market)的重要需求。

2.9.3.1.          資料範本具備全域(Global)和局部(local)管理能力

n   支援可全域使用的資料庫(例如多個開通流程共同使用)

n   提供選擇全域資料庫組成局部資料範本僅供某一特定流程使用

n   資料範本具有繼承能力,更改全域資料範本,各具備資料範本進行相應變更。變更局部使用資料範本不會影響其他局部資料範本。

2.9.3.2.          各資料項目和資料範本提供被工單重複使用的能力,即工單資料重複使用全域和局部資料範本

2.9.3.3.          能夠通過配置方式建立同一表單內的各資料項目之間的關聯、約束、運算等行為。

2.9.3.4.          具有多種自動生成表單的控制選項,完成分頁、換行、表格呈現、唯讀定義等方式以提供多種規則來實現各種資料呈現能力,如:

n   分頁、換行控制

n   表格呈現還是分頁呈現

n   合併不同資料群組到一頁

n   控制字體顏色,大小和表單分頁的背景顏色

n   控制資料格式,如唯讀定義

2.9.3.5.          能夠定義表單內各資料項目的顏色、字體等不同顯示方式如使用標準的CSS語言控制表單背景、資料項目顏色、字體等等。

2.9.3.6.          配置方式可根據不同輸入資料展現相關表單結構

2.9.3.7.          須提供可定制化的動態表單展現功能,表單的展現可以根據業務資料相關性、地點、SLA級別等資料驅動進行動態用戶頁面生成,

n   支持動態從不同介面的外部系統獲取資料

n   支援執行資料的運算 / 限制輸入值的範圍 / 提供欄位的預設值等

2.9.4.           工單生命週期設計模組(Order lifecycle Management, includes in flight change order)

工單的生命週期當中除了基本的流程引擎之外,還需要In-flight-change的智慧型處理機制。開通系統提供如下工單生命週期設計功能。

2.9.4.1.          工單生命週期包含以下狀態,系統需提供通過權限配置的狀態與狀態變更功能。

n   Cancelled:已取消狀態。在此狀態下可進行廢止、刪除、重新繼續和更新資料內容操作。

n   Completed:已完成狀態。在此狀態下可進行刪除和更新資料操作。

n   In Progress:正在執行狀態。在此狀態下可進行廢止,取消,錯誤,進行修訂,提出異常,暫停和更新資料操作。

n   Not Started:未開始狀態。在此狀態下可進行廢止,刪除,錯誤,暫停和更新資料操作。

2.9.4.2.          管理工單的生命週期,提供圖形化的設計工具配置各個生命週期的狀態改變與權限控制

2.9.4.3.          工單生命週期狀態的改變,可根據工單站自動進行相應變更。工單站生命週期包括:

n   Do:正在執行

n   Redo:重新執行

n   Undo:取消執行

2.9.4.4.          提供工單站生命週期管理配置功能

2.9.4.5.          在工單生命週期變化時如果工單站仍然需要,應提供以下功能配置:

n   Redo:重新執行此工單站

n   Undo and Do:取消執行原有工單站,採用新資料重新執行工單站

n   Do Nothing:忽略變化。例如,電話聯繫客戶工單站等。

2.9.4.6.          在工單生命週期變化時如果工單站不需要,應提供以下功能配置:

n   Undo:取消執行原有工單站

n   Do Nothing:忽略變化

2.9.4.7.          對異常工單、流程等的處理機制除可支援一般人工和異常流程機制外,還必須支持智慧型處理機制

n   人工異常處理方式:可於發生異常後跳轉 (jump) 到人工處理方式,進行人工處理,處理結束後由人工觸發繼續未完成的流程。

n   異常流程處理方式:可預設異常流程,發生異常後流程自動跳轉至異常流程進行處理,處理結束後異常流程自動返回未完成流程。

n   智慧變更處理方式:系統根據資料的來源和處理過程歷史自動判斷產生異常處理流程,比較流程各工單站資料之間的差異,根據預定義的邏輯分析流程的相關性,自動判斷還原至適當的工單站而不是單一的全工單還原。

2.9.4.8.          在沒有定義異常流程情況下,系統亦能根據預先定義的邏輯流程等資料的相關性,自動判斷還原至適當的工單站以支持異常情況處理,無需額外定義異常流程能力

2.9.4.9.          提供還原執行能夠實現無人為介入,實現智慧化控制

2.9.4.10.       系統提供圖形化的in-flight-change配置功能

n   對於客戶需求的工單修改(外部修改單) 必須根據客戶新的需求進行關聯的版本管理,工單狀態管理已經關聯的工單站狀態變更。要求配置簡單明確,客戶修改可以是任何關鍵資料的變化。例如客戶要求2M到4M頻寬之修訂,系統必須考慮,接入方式,埠容量,交互數據等所有關聯關係,自動完成相應的工單站狀態變更。

n   對於AMBIT內部修改需求(內部修改單),要求可以對在途工單任何資料進行修訂必須根據工單站中資料更新自動決定工單站狀態變化。要求配置簡單,明確。

n   對於某些異常,需能夠在自動變更處理基礎上提供人工流程進行處理。

2.9.5.           工單調度模組(Orchestration)

工單調度模組主要是從CRM產品管理中獲取與開通相關的產品,建立產品與產品服務、服務工單與業務資源的關係,並作為合併工單與獨立工單排程的模型。

2.9.5.1.          能夠定義及維護產品服務與業務資源的關係;

2.9.5.2.          能夠定義及維護產品服務動作(MACD:移機,新增,修改,退租)與業務資源動作之間的關係;

2.9.5.3.          能夠定義及維護多個工單中產品與產品服務之間的關係;

2.9.5.4.          能夠定義及維護產品服務之間的依賴關係;

2.9.5.5.          能夠接收不同類型的工單並驗證資料的完整性

2.9.5.6.          具備根據重點產品、重點業務、重點客戶識別服務的能力。根據產品服務設計將工單拆分為不同的產品服務。

2.9.5.7.          能夠提供多業務場景下的業務資源動態排程 (Orchestration)

n   能根據預先配置的各種產品服務間之間的依賴關係,自動產生和執行不同組合的排程計劃,而無須於系統預先制定各種各類的產品組合或促銷方案的開通工單排程

n   在產生排程計劃的過程中,系統能夠根據工單中的優先級、承諾的完工時間和所涉及業務之間的依賴關係,為每個工單動態產生的排程計劃。

n   無限制的自動產生不同業務組合的排程計劃。例如:GS、ALCK、ALIN產品服務,可以是分別的產品服務,也可兩兩組合,三個組合等不同排程計畫。

2.9.5.8.          依據設計拆分客戶工單到產品服務與業務資源

2.9.5.9.          開通過程監控

n   以產品為視角通過工單查看相關的服務工單、在途工單等各工單的資訊。

n   支援流程實例的在途資訊追蹤、條件查詢等能力,提供即時的監控工具,方便查看工單流程歷史以及狀態變化等。

2.9.6.           開通作業(Activation Center)

開通作業系統將與工單管理系統、綜合資源等系統共同協作,在開通流程中提供行網、固網、WIFI類業務的自動開通作業能力。

開通作業系統支撐之業務主要包括:LTE業務、互聯網業務、固網類業務、WIFI以及以上各種業務的組合。開通作業系統支撐的服務類型包括:新開、異動、移機、暫停、恢復、拆機、業務批量處理等。開通作業系統包含運行管控、系統介面、系統管理與配置管理四大模組。

2.9.6.1.          運行管控

2.9.6.1.1. Activation Center 應支援批量(Batch)啟動開通作業

n   批量啟動介面,包含XML, File等多種方式

n   批量啟動指令的Rollback,暫停,繼續功能,支援批量設置管理 – 例如批量錯誤閾值等

n   支援對批量啟動及結果的查詢功能

2.9.6.1.2. Activation Center 應支援計畫執行訂單及批量計畫開通作業(Schedule)

2.9.6.1.3. Activation Center 應支援即時啟動(Immediate) 開通作業

n   訂單執行優先與關聯順序

n   基於當前的訂單狀態規則之動作即不能在訂單已經註銷,失敗、完成等狀態進行更新操作

2.9.6.1.4. Activation Center 應支援開通作業監控

n   訂單監控支援給訂單維護員監視訂單的接收執行情況以及子訂單在網路設備設備、業務平臺執行情況,以便對訂單、子訂單執行進行控制,對異常訂單(失敗、超時)進行人工幹預和處理

n   支援異常和告警通知方式,如郵件、短信等

2.9.6.1.5. Activation Center 應支援開通作業異動處理

n   支援各種返回錯誤條件和Rollback的管理,例如,軟錯誤處理,重試邏輯或延遲處理

n   支援自動、手動禁用網路設備的選擇

n   系統會有誤差閾值配置,太多的硬故障之網路設備自動應禁用

n   如果網路設備被禁用其命令應放在等待隊列或發送至備用網路設備

n   支援手動或自動重新啟用網路設備

2.9.6.1.6. 訂單若出現異動,Activation Center應支援圖形化GUI以手工修改此訂單參數、暫停/重新執行此訂單或直接指定此訂單成功/失敗例如,當收到一條消息,指示啟動沒有成功地從網路設備,依據用戶定義之業務規則,啟動序列應支援以下選項

n   基於預先設定之重試次數,進行相應開通嘗試

n   記錄失敗的步驟並停止執行,等待手動處理

n   記錄失敗的步驟並繼續開通步驟下一個步驟或另行執行其他開通步驟

n   記錄失敗的步驟並停止執行失敗的步驟和回退先前執行的所有開通步驟

2.9.6.1.7. Activation Center應支援網路設備連接管理這應包括:

n   管理連接/斷開Session請求

n   管理主/輔連接請求

n   維持網路設備之最大連接數

2.9.6.1.8. Activation Center應支援圖形化訂單查詢支援給訂單維護人員對於訂單、子訂單內容的查詢

2.9.6.1.9. Activation Center應支援圖形化人工創建訂單介面,類比業務系統造出符合系統工儲存格式要求之訂單,可以用於cutover和測試

2.9.6.1.10.    Activation Center應支援使用者測試環境和測試程式,可以在不影響正常業務處理情況下完成系統的測試,測試分為以下幾類:

n   介面測試,該測試實現對各個介面的連通性、資訊交互以及功能處理等的測試此測試功能包括與網路設備之間的介面測試、與服務開通系統之間的介面測試,以及與服務開通系統其他部分的測試

n   訂單測試,該測試可以完全類比正式運行環境中的狀態,在不影響系統正常業務處理的情況下實現全流程測試和功能測試

2.9.6.1.11.    Activation Center應支援對訂單執行中的日誌進行進行查詢,以便分析訂單執行中的問題Activation Center 應支援開通作業異動處理

2.9.6.1.12.    Activation Center應支援對訂單處理等進行相應的統計分析,該系統應支援完成者日誌記錄功能下麵詳細介紹應保持在日誌中:

n   請求的日期

n   請求的時間

n   請求的類型

n   請求的狀態

n   請求ID,資料

2.9.6.2.          系統介面

2.9.6.2.1. Activation Center 應支援開通北向(Upstream)介面

n   Activation Center應支援XML、JMS、WebService、HTTP等介接方式

n   介接多個上游系統(例如自服務,訂單錄入系統,EAI等)

n   該系統應支援上游系統對請求當前狀態之查詢

2.9.6.2.2. Activation Center 應支援開通作業同步和非同步的介接方式

2.9.6.2.3. Activation Center應支援LTE域、Fixline域、IP域網路設備,並支援相應Session控制與管理防止網路設備過載相關網路設備包括但不限於:

n   HSS

n   PCRF

n   RCS

n   VMS AS

n   CRBT AS

n   SMSC(IP-SM-GW AS)

2.9.6.2.4. Activation Center應支援各種介接協議,包括但不限於:

n   HTTP / S,SOAP / XML

n   CORBA(Java解釋器)

n   LDAP

n   SNMP(V1,V2和V3)

n   TL1

n   TCP / IP協議Telnet

n   TCP / IP的FTP

n   TCP / IP socket

n   SSH/ SSH協議

n   可擴展的Java工具包

2.9.6.2.5. Activation Center應支援透過EMS非直接介接之網路設備開通作業

2.9.6.3.          系統管理

2.9.6.3.1. Activation Center應支援使用者資料管理,包括用戶名,密碼,使用者組等資訊

2.9.6.3.2. Activation Center應支援用戶許可權管理

2.9.6.3.3. 用戶角色管理Activation Center 應支援開通作業異動處理

2.9.6.3.4. Activation Center應支援支持密鑰分發到每個服務器機制,確保定制的安全數據的安全傳輸

2.9.6.3.5. Activation Center應支援對系統的關鍵安全資訊進行加密存儲

2.9.6.3.6. Activation Center應支援應完成者日誌記錄功能下麵詳細介紹應保持在日誌中:

n   請求的日期

n   請求的時間

n   請求的類型

n   請求的狀態

n   請求ID資料日誌

2.9.6.3.7. Activation Center應支援維護應用程式和網路設備之間exchanged所有原始數據的審核跟蹤

2.9.6.3.8. Activation Center應支援系統運行狀態監視和控制並向協力廠商支援相應之SNMP監控介面

2.9.6.4.          配置管理

2.9.6.4.1. Activation Center 應支援開通作業服務配置管理,支援多種網路技術與業務之融合產品開通,包括

n   行動電話服務(3G,4G,IMS等)

n   VAS(IPTV等)

n   固定網路服務(FTTx,DSL等)

n   MVNO服務

n   WIFI服務

2.9.6.4.2. Activation Center應支援圖形化訂單的欄位和格式快速設計

n   支援訂單欄位合法性校驗規則

n   支援圖形化從融合產品訂單拆解為單一產品服務,再拆解為網路開通服務及進一步拆解為網路腳本

n   支援圖形化定義需要的基礎資料資訊,如產品類別、服務類型、設備類型、網路設備類型等

n   完成訂單間或子訂單間關聯關係的配置如常見的RollBack關係:Rollback Order對原有訂單進行rollback操作,可有不同的處理策略

2.9.6.4.3. Activation Center應支援圖形化對定義好的網絡腳本、開通服務可以在不同的開通中重用

2.9.6.4.4. Activation Center應支援多個版本部署方式,新舊版本可以在系統中共存

2.9.6.4.5. Activation Center應支援圖形化服務time out值、重試次數、異常處理觸發條件、執行結果判斷等

2.9.6.4.6. Activation Center應支援多種網路設備管理

n   網路設備路由規則配置依據網路設備類型、資源資訊、地域資訊、號段資訊、SLA資訊等資訊進行管理,並根據這些資訊構建相應規則在綜合啟動系統組態規則,確定把指令發送到目的網路設備

n   支援配置網路設備所屬網路設備類型,網路設備通信協定,主備用等資訊

n   配置網路設備接入的控制屬性,不同的重試次數,指令發送次數,連接數量,工作時間等

2.9.6.4.7. Activation Center應支援多種網路設備模版,例如HSS模版,AS模版等,支援配置網路設備模版類型,通信協定,主備用等資訊

2.9.6.4.8. Activation Center 支援相應的外掛程式開發和部署工具,便於對上述的各種配置進行管理、打包和部署

 

 

 

 

“CRM System and the Deployment Project”

Request for Proposal

 

 

 

 

 

Ambit Microsystems Corporation

Jan 2, 2014

 

 

 

 

 

 

1.   Project description

     In view of the Ambit 4G communication services operating strategy, we are seeking proposals from the general public for its Customer Relationship Management (CRM) system.  The accepted solution is expected to reduce human errors, save time and paper consumption, and integrate with other systems to enhance business performance.

1.1. Project objectives

The project name is “CRM System Deployment and Maintenance Project,” its goal: to set up an electronic system which integrates applications of the accounting system, operating system and database to achieve effective analysis and management of the whole system. Hereinafter this is referred to as the “Project”.

1.2. Project contact window

  • Main contact window:

Contact: Ambit Information Center: Zhuang Yingchi

Address: No. 32, 2f Jihu Rd, Neihu District Taipei City, Taiwan 11492

Tel: (02)7733-0566 ext. 12726

Fax: (02)7745-0927

e-mail:matthew.yc.chuang@ambit.com.tw

 

  • Support contact window:

Contact: Ambit Operations Department: Zhang Guowei

Address: No. 32, 2f Jihu Rd, Neihu District Taipei City, Taiwan 11492

Tel: (02)7733-0566 ext. 12725

Fax: (02)7745-0927

e-mail:stephen.kw.chang@ambit.com.tw

 

  • Vendor’s submission window:

Contact: Ambit Information Center: Yang Daotian, deputy general manager

Address: No. 32, 2f Jihu Rd, Neihu District Taipei City, Taiwan 11492

Tel: (02)7733-0566 ext. 12707

Fax: (02)7745-0927

e-mail:sky.dt.yang@ambit.com.tw

Unless otherwise recommended by the Company, no one other than the above people can be contacted regarding issues of the Project Proposal.

1.3. Deadline for the project proposal

The following schedule set up by Ambit is aimed at obtaining optimal information, and adjustment may be made depending on the business requirements. All proposals must be delivered before January 23, 2014.

Project Date of completion
Issue of “Request for Proposal” Jan 23, 2014
Deadline for submission of “Project Proposal” Jan 23, 2014
“Proposal” Briefing Before Feb 19, 2014

 

1.4. Performance conditions

The following conditions are strict requirements a vendor has to meet in responding to this “Request for Proposal”. Vendors failing to comply with the terms and conditions will be deemed disqualified.

1.4.1.           Ambit is entitled to request additional written or oral information regarding a vendor’s submitted proposal.

1.4.2.           Vendor must send the response to Ambit before the above deadline, any delay may cause the vendor to be disqualified.

1.4.3.           Vendor selection criteria is based on whether the “Proposal” meets Ambit business needs, not just the price.

1.4.4.           Ambit reserves the right to modify the content of this “Request for Proposal” before it implementation, including the right to split the awarded contract to different vendors.

1.4.5.           Unless notified otherwise by Ambit, all questions related to the “Request for Proposal” must be submitted by writing (including email).

1.4.6.           When Ambit needs to seek further information from a vendor and the vendor is unable to provide a clear answer, Ambit may seek the answer from other vendors (without notifying the said vendor).

1.4.7.           Each vendor is required to deliver five written copies of the “Proposal” before the deadline, while sending an electronic version by email to the above contact windows at the same time. All electronic documents must be made using the Office suites(such as MSWord); if the file size is too large, it can be stored on a CD.

1.4.8.           Color pages of product introduction provided by a vendor should be sent individually, along with the content list to facilitate reading.

1.4.9.           If a vendor invites other vendors to participate in this project, the submitted “Proposal” should clearly provide the relevant vendor’s information and the division of labor; no third party should be delegated to perform the duties without Ambit’s prior consent; all responsibilities related to contractors in the project should be borne by the bidding vendor, and the vendor is the only party that the company will sign the contract with.

1.5. Confidentiality

Vendors must keep all information of the “Request for Proposal” and other electronic communication information with Ambit confidential. Matters related to confidentiality shall be separately signed by both parties in a “Confidentiality Agreement”.

1.6. Statement

Vendors must use the information provided by Ambit for project evaluation, the information provided by Ambit is for reference only, actual information shall be based on the actual business volume.

1.7. Cost and vendor selection

1.7.1.           Costs related to “Proposal” preparation, additional information and representation before signing the contract shall be borne by the vendor.

1.7.2.           Issuance of this “Request for Proposal” does not mean that Ambit has to accept any one of the submitted “Proposal.” Ambit also does not guarantee that a contract will be signed with any one or more of the vendors. For the best interest of Ambit, if the “Proposal” has any irregularities or non-formal content, it will be ignored in the review. In the above situation, Ambit may require the vendor to slightly modify the content of the “Proposal” (except for price-related content).

1.7.3.           After receiving a “Proposal”, Ambit will conduct a preliminary review. Vendors passing the review shall be briefed, and the briefing will be conducted in locations designated by Ambit. Cost related to the briefing shall be borne by the vendor. Ambit has the right to decide which vendor to be briefed according to their provided “Proposal”, those vendors who are not briefed should not have any objections whatsoever.

Ambit may contact the vendor’s customers, to learn whether customers are satisfied with a vendor’s products and services. Vendors must provide reference customer information, which should include work-related and telecommunication-related customers.

 

 

 

2.   Requirements

The functional requirements for the system are described below, the actual content of the functional requirements should be based on the results obtained in the analysis stage and confirmation of the USER department.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.6. Service acceptance for customer orders

Service acceptance of customer orders mainly deals with AP form process, including customer order setup, review, confirmation and sending, exception handling and other functions, to achieve end-to-end full-service, full channel order processing. Moreover, order processing is a core business function module in a customer management system, so it needs to be highly flexible, stable and scalable. Service acceptance should support process customization, while maintaining process uniformity at the same time.

2.6.1.1.          The support includes: service provision / change / cancellation information, product provision / update / cancel information and other order processes.

2.6.1.2.          The channels of service acceptance could be FAX, eMail, Web, APP, shops and other channels, and need to be integrated with image file management system, so the person entering the order can handle it as attachment.

2.6.1.3.          Service acceptance is the basis for all service provision changes, such as: new provision and changes to basic and value-added services, changing Internet access fees, automatic suspension / restore, suspension due to owed payment / restore when paid, etc.

2.6.1.4.          Changes during service acceptance: A service ticket can be changed before its completion(specific business rules could be set up as to at what stage a service ticket could be changed). Information that can be changed in a service ticket includes fee level, contact phone number, etc.

2.6.1.5.          The service ticket records information related to the services / products, where the information related to service provisioning should be sent to the OSS system (Provisioning and Activation systems) for service activation.

2.6.1.6.          Provide convenient and simple steps for order entry and update, for example, when a customer makes a one-time purchase of large volume of services, or make changes to large volume of services / products.

2.6.1.7.          The provisioning process must provide the following system functions:

n   Customer information query: to check whether the customer data already exists

n   Provision checking: enter customer ID and check the blacklist.

n   Enter application information: including address, contact person, dealership code, project, fees, selected services, provision and other information, and various fees displayed by the viewing system.

n   Status query during service provision: including entry date, work order progress, or error status and other information.

n   Provision results query: after an account is successfully set up and service started, the customer-related data could be queried in the system, including customer, account, status and installed assets.

2.6.1.8.          While accepting new service or during setup, it should allow selection of various promotions, including cross-product discount and product bundles.

2.6.1.9.          Before service provision, the integrity and accuracy of service ticket information must be checked:

n   Check whether the customer account exists.

n   Whether the various product definitions for this service ticket are complete, whether there are related promotional programs.

n   According product dependency, find out the additional required services to meet the needs of the service ticket. For example: a customer needs multimedia services, then he must first have Internet access. If the required product does not exist, then it is necessary to remind the data entry staff or send error information to related systems.

2.6.1.10.       The payment method for a customer’s one-time charge in service application should be recorded in the service ticket. This fee can be integrated with back office billing system or notification to the accounting department, depending on the needs.

2.6.1.11.       Customer needs to cancel service after service provision cancellation period has passed. The system provides contract termination function:

n   Query customer information: check whether the customer information already exists.

n   Enter Cancel Application: select reason for cancellation and check outstanding payment as well as default fine amount.

n   Check cancellation result: after successfully disabling the billing and provisioning systems, query customer-related information in the customer service system, including customer, account, user disable status and removal of installed assets.

2.6.1.12.       When basic and value-added services are changed, the system can automatically detect whether newly provisioned service and existing services are related or mutually exclusive, and provide real-time information to front-end staff, and enable the back-end activation to be completed smoothly.

2.6.1.13.       Specific services in the provision could be canceled or changed.

2.6.1.14.       Service change may involve the contract; before making any changes, the current status of the contract should be confirmed, to see whether there are any restrictions, such as: the minimum required usage period, early termination penalty, etc., so that the user can be alerted when making such changes.

2.6.1.15.       Provide early renewal or contract extension management, including flexible fines calculation:

n   Provide early renewal and contract extension process.

n   After contract renewal and before the next contract becomes effective, if the customer wants to terminate the contract, the customer needs to pay fines for the first and second contract.

n   The one week appreciation period has no fees; if not canceled after one week, then there will be fees for all periods.

2.6.1.16.       Provide contract expiration alert message; can set up when to send the expiration notice, through which channel, message content and message target, etc.

2.6.1.17.       Support service ticket cancellation. Cancellation could be initiated manually, or according to business rules set up by other operation systems. Cancellation function of the service ticket should also be able to cancel all ticket-related actions which were started already (to restore to the initial state). The system must record the reasons for service ticket cancellation.

2.6.1.18.       Can provide immediately available user interface for a user to control the order. The user interface includes, but is not limited to, product catalog, product selection, product comparison, product attributes, up-selling and cross-selling information, price tips, quote combination, etc.

2.6.1.19.       Can display in one window all relevant customer data, assets purchased, billing information and recommended offers, to facilitate complementary sales / cross-selling.

2.6.1.20.       Can provide guide text to help staff to provide product / service recommendations.

2.6.1.21.       Can handle promotional campaigns, customer service or large number of orders from one individual.

2.6.1.22.       Can provide complete order life cycle management in the work-flow, from customer profile, business orders acceptance to submission of orders to the back-end system.

2.6.1.23.       Can create order, to change the fees plan (up / down sales).

2.6.1.24.       Can create order, to add / remove options (cross-selling, for example, with value-added services).

2.6.1.25.       Can create order, to modify the billing account assigned to the product.

2.6.1.26.       Can handle the delivery details defined in the order in order to correctly deliver products and services to the customer.

2.6.1.27.       Can handle large number of orders resulting from purchases or sales in B2B and B2C marketing environment.

2.6.1.28.       Can generate order form with pre-filled information, including customer data and previously obtained customer information.

2.6.1.29.       Can provide immediately available order interface and order processing process according to different order types.

2.6.1.30.       Can track future order.

2.6.1.31.       Provide a uniform customer order service acceptance system, according to different store type, provide different input screen, to facilitate store business.

2.6.1.32.       Integrate with number management system, to facilitate customer to select phone number at the time of order acceptance.

2.6.1.33.       Allow a customer to update summary information after the service has been initiated.

2.6.1.34.       Can initiate penalty rule when a user decides to interrupt service during the contract period, and define penalty rules according to whole payment, payment discount or payment proportion.

2.6.1.35.       Can record order changes history.

2.7. Shop location management

Shop location includes outlets, stores and other channels, such as different types of channels, with different shop functions, including customer information query, processing of provision change, customer service center, processing of billing and other related issues and operations. The required functions are described as below:

2.7.1.           Set up shop location code and relevant shop location information, such as shop address, access type, company’s GUI number, staff, etc.

2.7.2.           When a customer signs up for service provision, the shop location code or staff number recorded in the service ticket could be entered into the system in order to facilitate subsequent statistical analysis.

2.7.3.           Gate number application, classification, allocation, management of sales and service withdrawal.

2.7.4.           Can manually or automatically allocate dynamic gate number, acquire, retain and use the gate number in the system and manage according to shop location.

2.7.5.           Sales project, bonus, APP, cloud product offer and service withdrawal management.

2.7.6.           Support traditional / electronic paperless operation, blacklist management, fee plane selection, sign up, modification, query and cancellation.

2.7.7.           Store-front expertise, questions database and auxiliary sales system and fee plan, project and mobile phone user description.

2.7.8.           Provide the most suitable fees calculation.

2.7.9.           Customer complaints job forwarding, follow-up and response management, and customers are able to find relevant information in our customer self-service website.

2.7.10.       Other functional requirements for outlets

2.7.10.1.       Kiosk or Pad enable customers to check the latest information on all mobile phones, peripherals, pick-up stores, mobile Internet, home broadband, international roaming fee plans and other services, thereby reducing the workload of store staff. The customer can also go to the front customer service counter to obtain necessary information to improve service quality and increase customer satisfaction.

2.7.10.2.       Bill payment processing

2.7.11.       Management of permissions

2.7.11.1.       Each shop location can only find information related to its own shop.

2.7.11.2.       System functions related to authorization, such as signup application, payment processing, customer requirements, etc.

2.7.11.3.       Can define different types of channels, and what data fields can be queried by a shop location.

2.7.12.       Reporting Requirements: Each shop location’s sales reports, including total sales, sales by product category, number of new customers, submitted customer cases, etc.

2.8. Gateway number is portable

2.8.1.           Set up internal centralized database (LNPDB) and Service Management System (LSMS)

2.8.1.1.          Knowledge of the provisions of “Rules for Mobile Number Portability Service” or the relevant provisions of the NCC telecommunication regulations are required, in order to plan the Ambit portable user database in compliance with the rules and regulations.

n   Portable user database accuracy, security and normal operational functions must be ensured.

n   Normal operation and function of portable user data exchange equipment must be ensured.

n   Must have complete data backup and redundancy measures.

n   Must set up data records that are able to retain more than six months’ transaction history.

n   Must set up redundant portable user database equipment (including database systems, data content and database servers, all should have at least two sets)

n   In order to establish proper communication routes, the portable user database must be able to be simultaneously exchanged.

2.8.1.2.          LSMS is responsible for processing and exchange of CNPDB information types as follows:

n   Information related to portable service application procedure

n   Information related to gateway number cancellation procedure

n   Information related to update procedure

n   Information related to database query

n   Information related to database restore process

2.8.1.3.          LSMS data exchange timing, format, content and protocols must meet the specifications of centralized database management committee or NCC, and should include:

n   Portable user database update deadline after receiving NPAC notification.

n   Method and procedure in checking the accuracy of portable user database and database update.

n   Data exchange interface specification, data format, procedures and test methods.

2.8.1.4.          Requirements for the internal centralized database(LNPDB) are as follows:

n   when the data operator has completed the transfer operation and starts to modify the related information, the LNPDB database update time: 40 minutes.

n   When a user or contract worker discovers a network configuration problem which has caused normal users unable to receive and send messages, the contract worker can request NPAC to check all or specific databases, LNPDB database internal check time: minimum 20 minutes, maximum 2 hours.

n   When LNPDB data is destroyed due to force majeure factors, request can be made to NPAC to help re-build the LNPDB, the database rebuild time: 4 hours.

n   When LNPDB update fails, number of times NPAC resends the update request: 3 times.

2.8.1.5.          Must integrate with CRM / Billing to reduce implementation cost.

2.8.1.6.          Other related requirements are as follows:

n   Before using the centralized database, database exchange test must be carried out between portable user database and other operators, and Type II telecommunications enterprises.

n   Before using the centralized database, within 1 hour after receiving the transfer-in notice, the portable user database must be updated and other necessary routing information settings must be completed.

n   Before using the centralized database, within 12 hours after receiving the termination notice, the portable user database must be updated and other necessary routing information settings must be completed.

2.8.2.           Administrative operation system (SOA) in portable service setup

2.8.2.1.          Portable service transaction logs generated by the application software must be converted into a standard format and content as required by message exchange, and send to CNPDB or other related operators.

2.8.2.2.          Information related to the portable user sent by CNPDB or other related operators must be received and converted into a format and content usable by the application software.

2.8.2.3.          The type of exchange information includes:

n   Information related to portable service application procedure

n   Information related to gateway number cancellation procedure

n   Information related to program cancellation

n   Information related to program modification

n   Information related to dispute handling

n   Information related to update procedure

n   Information related to database query

2.8.2.4.          Message exchange timing, format, content and protocol must meet the specifications of centralized database management committee (NPAC), and the related requirements are as follows:

n   Response time of the transfer-out operator to transfer-in operator’s request: before the end of the 2nd full business day after receipt of the application materials.

n   Time from transfer-in operator’s application to contract start date: the transfer-in operator must submit the application at least 5 full working days before the start date of the contract.

n   Time from the contract start date to update completion of all databases: 1.5 hours.

n   Time from gateway number cancellation to the number’s return to the original number allocator: 7 full working days from the date of service termination.

n   Time from service termination to completion of update of all databases: 1.5 hours.

n   Time for cancellation consultation between transfer-in operator and transfer-out operator: 1 day, but not more than the finishing time specified in paragraph 2.2 above.

n   Time for modification consultation between transfer-in operator and transfer-out operator: 1 day, but not more than the finishing time specified in paragraph 2.2 above.

n   When transfer-in operator has finished transferring the number and starts modifying related information, the database update time: 1.5 hours.

n   When a user or contract worker finds that network configuration problem makes the user unable to receive and send messages normally, the contract worker can request NPAC to check all or specific databases, the database check time: minimum 1.5 hours, maximum 6 hours.

2.8.2.5.          Message exchange should be able to be run either automatically or manually.

2.8.2.6.          Historic records for message exchange should be kept for queries or reports.

2.8.2.7.          Information can be handled respectively according to operators (e.g.: TWM 3G or FET3G).

2.8.2.8.          Provide portable user data exchange progress query interface.

2.9. Service provisioning

2.9.1.           Order management (Order and Service Management)

The system will combine the concepts of ETOM in TM_Forum and SID model in the planning of new services and order management system architecture, to cope with market change, adapt to full-service integration, and support diverse, fast and shared provisioning and modification requirements. Support capabilities include the following:

In view of the development system framework, the new work order system needs to meet the requirements of TMF framework, and be in line with Ambit business development plan.

2.9.1.1.          From a business perspective, mobile network, fixed network, WIFI and various product types are integrated, and the new work order system is required to support diverse products and product bundles.

2.9.1.2.          In view of work-flow, the new work order system is required to include not only simple business processes, but also support for complex processes, involving both automatic and manual work station, complex multi-task error control station and other key business scenario.

2.9.1.3.          From a provisioning-related business perspective, the new work order system can handle business platform, core networks, access networks and resources of partners …etc., to meet complex resource requirements.

2.9.2.           System items

2.9.2.1.          Work order design module (Service Order)

Work order design includes work order setup according to requirements of the design stage, business logic, work order template and operator roles. Provisioning-related components are broken down after front-end and back-end consultation, and work station requirements are set according to overall process templates.

n   Graphical design tools are needed to provide user interface customization: work order station (manual station, automatic station, rules / logic, delay, parallel stations); branching, merging, jumps and parallel processing. Reusable processes (reuse) are provided in the business design process, the sub-process mechanism

n   Must provide normal / abnormal process management: smart decision and restore function, and abnormal flow processing (in flight change)

n   Must provide workgroup management features including workgroup permissions, working hours, holidays (non-working days), and be able to allocate and configure work order roles and permissions.

n   Must provide time management features including working days management, work time management, work station time management, process time management, work order management, and project start-time configuration capabilities.

n   Must provide rule-based alert and monitoring features such as time-triggered, event-triggered monitoring and sending of SMS messages.

n   Must provide work station management features including various workstation tasks(Tasks), staff roles (Role), workstation data interface, workstation error configurations.

n   Must provide uniform rules management (rule task): queue / event trigger / data trigger / user customization conditions.

n   Must provide uniform security configuration including interface control and security certification.

n   Must include support for version management of design templates, the design templates includes data element, process, work station, work groups, business logic, interface control, etc., which must be stored in XML format. The system can support parallel processes of multiple versions.

n   Must have targeted provisioning availability according to SLA (Service Level Agreement), product, region, individual customer needs, support time, process (or branching processes), customer priority, etc.

n   Selection of different systems or business resources according to geographical region.

n   Selection of support work groups according to customer level.

n   Depending on customer level, the automatic work station should provide priority, and manual work station should have color-coded identification.

n   Set up different time alerts for operators according to different customer and product information.

2.9.2.2.          Provide viewing and processing capabilities for work orders at various stages, including:

n   View work order process history, view notifications history, cancel work order, suspend work order, resume work order, duplicate work order, modify work order, issue error alert, etc.

n   Through query using multiple combinations,  the system can define any data fields as query condition, such as customer name, address, area, work order status, work status, work station condition, individually or in combination, and provide query saving function.

2.9.3.           Data template design module

Data element is an important element in the system, different combination of data element shows different business work orders. Therefore, data template design is an important requirement and a measure designed to ease the provisioning system to respond quickly to market demand (TTM, Time to Market).

2.9.3.1.          Data template can be globally and locally managed.

n   Support databases that can be used globally (such as multiple provisioned process running simultaneously).

n   Select global database to form local data template for use only in a particular process.

n   Data template can be inherited, by changing the global data template, each inherited data template will have the corresponding changes. Changes in local data template will not affect other local data templates.

2.9.3.2.          Each data item and data template can be reused, so that work order can use the global and local data template repeatedly.

2.9.3.3.          Can set up relationships, constraints and calculation among the data items within the same form through configuration.

2.9.3.4.          Have control options to automatically generate a form, complete pagination, line change, form display, read-only rules and other methods, providing various ways of data presentation, such as:

n   Pagination and line control

n   Table display or paged display

n   Merging different data groups to one page

n   Control font color, size and form page background color

n   Control data format, such as read-only

2.9.3.5.          Can define the display color, font and other displays of the various data items in a form, for example, using standard CSS to control form background, item color, font, etc.

2.9.3.6.          Can be configured to show related form structure according to input data

2.9.3.7.          Can be customized to provide dynamic form display, and the form display is dynamically generated according to data relevancy, location, SLA levels and other information.

n   Support dynamic data access from different external system interfaces

n   Support data calculation / limit range of input values ​​/ provide default values for fields

2.9.4.           Work order life cycle design module (Order Lifecycle Management, includes in flight change order)

In a work order’s life cycle, in addition to the basic process engine, there must also be intelligent processing mechanism of In-flight-change. The provisioning system provides the following work order life cycle design capabilities.

2.9.4.1.          The work order life cycle consists of the following states, and the system must provide status and status change function through permission configuration.

n   Canceled: Canceled status. This status allows cancel, delete, resume and update operation.

n   Completed: Completed status. This status allows delete and update operation.

n   In Progress: in-progress status. This status allows cancel, error, change, exception, pause and update operation.

n   Not Started: not-started status. This status allows cancel, delete, error, pause and update operation.

2.9.4.2.          Manage work order life cycle, provide graphical design tool to configure the status of each life cycle and access control

2.9.4.3.          Work order life cycle status can be changed automatically according to work order. Work order life cycle includes:

n   Do: executing…

n   Redo: run again

n   Undo: cancel execution

2.9.4.4.          Provide work order life cycle management configuration capabilities

2.9.4.5.          When a work order life cycle changes, the work station must be configured to provide the following functionality:

n   Redo: execute the work order again

n   Undo and Do: cancel the execution of the original work order, and execute the work order again using new data

n   Do Nothing: ignore the change. For example, contacting customer by phone work order, etc.

2.9.4.6.          When a work order life cycle changes, if the work station is not required, it should provide the following function configuration:

n   Undo: cancel the execution of the original work order

n   Do Nothing: ignore the change

2.9.4.7.          For abnormal work order and processes, in addition to the general manual exception handling mechanism, there must also be support for intelligent handling mechanism

n   Manual exception handling: can jump to manual handling after exception occurs; after manual processing is finished, the unfinished process is triggered manually.

n   Exception handling process: exceptions can be preset; when exceptions occur, the work-flow automatically jumps to exception handling process; after finishing the exception handling process, it automatically returns to the unfinished work-flow process.

n   Intelligent change processing: the system automatically determines the exception handling process according to data source and historical records, compares the difference between work orders, analyzes the relationships between the processes according to predefined logic and automatically determines to restore to the appropriate work station rather than a single full work order restoration.

2.9.4.8.          In the absence of defined exception processes, the system can also automatically determine the appropriate work order to restore according to pre-defined logic or process relationships, without additional defined exceptions.

2.9.4.9.          Provide restoration without human intervention, to achieve intelligent control

2.9.4.10.       The system provides graphical in-flight-change configuration features

n   For work order changes (external changes), there must be management of related versions according to customer needs, and management of associated work order status change. The configuration must be simple and clear, customers can change any key data. For example, a customer requests change to 2M to 4M bandwidth, the system must take into account access methods, port capacity, interactive data and other relationships, and automatically complete the corresponding work order status change.

n   For AMBIT internal changes (internal change order), it is required to be able to change any in-process work order, and automatically determine the change status according to work order update status. The configuration needs to be simple and clear.

n   With certain exceptions, it must be able to provide manual exception handling in addition to the automatic change process.

2.9.5.           Work order scheduling module (Orchestration)

Work order scheduling module is mainly involved in obtaining related products from CRM product management, establishing relationships between product and product service, work orders and services resources, and as a scheduling model in combined work orders or independent work order.

2.9.5.1.          Can define and maintain relationships between products, services and business resources;

2.9.5.2.          Can define and maintain relationships between product and service operations (MACD: move, add, change, delete) and business resources;

2.9.5.3.          Can define and maintain relationships between multiple work order products and services;

2.9.5.4.          Can define and maintain dependencies between products and services;

2.9.5.5.          Can accept different types of work orders and verify data integrity

2.9.5.6.          Can identify service according to key products, key business and key customers. Can split work order into different products and services according to product and service design.

2.9.5.7.          Can provide dynamic resource allocation for different business scenarios  (Orchestration)

n   Can automatically generate and execute different combinations of scheduling schemes according to the dependencies between pre-configured products and services, without the need for the system to set up product combinations and product promotions

n   While generating schedules, the system can dynamically generate a schedule for each work order according to priority, completion time and service dependency.

n   Automatically generate unlimited schedules for different service combinations. For example: for GS, ALCK, ALIN products and services, the schedule could be separate products and services, or combinations of two, three products and services.

2.9.5.8.          Split work order’s products and services according to design

2.9.5.9.          Activation of process monitoring

n   View service order, in-progress work order and other work order related information from a product perspective.

n   Support process instance information tracking, conditional query, provide real-time monitoring tools to facilitate the view of work order history and status change.

2.9.6.           Activation(Activation Center)

The Activation Center will work together with the work order management system, integrated resource system and other systems to provide automatic activation capability for mobile network, fixed network, WIFI and other services.

Services supported by the Activation Center include: LTE service, Internet service, fixed network service, WIFI, and other service combinations. Service types supported by the Activation Center include: new account activation, changes, moving, pause, resume, split, batch processing, etc. The activation system includes four modules: execution control, system interface, system management and configuration management.

2.9.6.1.          Execution control

2.9.6.1.1. Activation Center should support batch activation.

n   Batch activation should support XML and other File formats.

n   Batch activation commands such as Rollback, Pause, Resume and other functions should support batch settings management – for example, batch error threshold, etc.

n   Support batch activation and result query

2.9.6.1.2. Activation Center should support scheduled order execution and batch order activation

2.9.6.1.3. Activation Center should support immediate activation

n   Order priority and execution sequence

n   Execution is based on the current status of the order, for example, update is not allowed after the order has been canceled and failed to be completed.

2.9.6.1.4. Activation Center should support operation monitoring

n   Order monitoring enables the order maintenance staff to monitor order acceptance, execution of sub-orders in the network device and the service platform, in order to control order and sub-order execution, to manually interfere and handle abnormal orders (failure, timeout)

n   Support error and alarm notification, such as e-mail, SMS, etc.

2.9.6.1.5. Activation Center should support exception handling

n   Support various error conditions and rollback management, for example, software error handling, retry logic or delays

n   Support manual and automatic options in disabling network device

n   The system has error threshold configuration, network device with too many hardware failure should be automatically disabled

n   If a network device is disabled, its command should be placed in queue or sent to an alternative network device

n   Support manual or automatic re-enabling of network device

2.9.6.1.6. In case of order exceptions, the Activation Center should support graphical GUI to manually modify the order parameters, pause / re-execute the order or directly specify the order success / failure. For example, when a message indicates that the order failed to execute in the network device according to user-defined business rules, the Activation Center should support the following options

n   Re-try based on pre-set number of retries

n   Log failed steps and stop execution, and wait for manual processing

n   Log failed steps and continue next step of the activation, or execute other steps

n   Log failed steps and stop execution, and return to the previous activation step

2.9.6.1.7. Activation Center should support network device connection management, including:

n   Management of connect / disconnect session request

n   Management of master / slave connection request

n   Maintain maximum number of network device connections

2.9.6.1.8. Activation Center should support graphical query, for order maintenance staff to query order and sub-order content

2.9.6.1.9. Activation Center should support graphical manual creation of order interface, to create orders that meet the format requirements of the system, for use in cutover and testing

2.9.6.1.10.    Activation Center should support user test environment and test programs, to test the system without affecting the system’s normal business process. The test can be divided into the following categories:

n   Interface test, which tests interface connectivity, interaction and information processing capabilities, including interface test among network devices, between service provisioning systems, as well as between service provisioning system and other parts

n   Order test, which tests the status in a simulated operating environment, to achieve whole process and functional testing without affecting the normal business process

2.9.6.1.11.    Activation Center should support query of the order execution log, to analyze execution problems. The Activation Center should support execution exception handling

2.9.6.1.12.    Activation Center should support statistical analysis of the processed order, the system should have detailed function logs and details should be kept in the log:

n   Request date

n   Request time

n   Request type

n   Request status

n   Request ID, info

2.9.6.2.          System interface

2.9.6.2.1. Activation Center should support activation of Upstream Interface

n   Activation Center should support XML, JMS, WebService, HTTP and other interfacing methods

n   Interfacing with multiple upstream systems (such as self-service, order entry systems, EAI, etc.)

n   The system should support current status query by Upstream systems

2.9.6.2.2. Activation Center should support both synchronous and asynchronous interfacing methods

2.9.6.2.3. Activation Center should support LTE domain, Fixline domain, IP domain network devices, and support the corresponding Session control, manage and prevent network device overloading, including but are not limited to:

n   HSS

n   PCRF

n   RCS

n   VMS AS

n   CRBT AS

n   SMSC(IP-SM-GW AS)

2.9.6.2.4. Activation Center should support various interfacing protocols, including but are not limited to:

n   HTTP / S, SOAP / XML

n   CORBA (Java interpreter)

n   LDAP

n   SNMP(V1, V2 and V3)

n   TL1

n   TCP / IP protocol Telnet

n   TCP / IP FTP

n   TCP / IP socket

n   SSH / SSH protocol

n   Extensible Java toolkit

2.9.6.2.5. Activation Center should support activation through EMS indirect network interface

2.9.6.3.          System management

2.9.6.3.1. Activation Center should support management of user data, including user name, password, user groups and other information

2.9.6.3.2. Activation Center should support user permission management

2.9.6.3.3. User Role Management: Activation Center should support activation exception handling

2.9.6.3.4. Activation Center should support server encryption key distribution, to ensure secure transmission of customized data

2.9.6.3.5. Activation Center should support encryption of critical information and encrypted storage

2.9.6.3.6. Activation Center should support completion logging, the following detailed description should be kept in the log:

n   Request date

n   Request time

n   Request type

n   Request status

n   Request ID information log

2.9.6.3.7. Activation Center should support audit trail of raw data exchanged between maintenance applications and network devices

2.9.6.3.8. Activation Center should support system status monitoring and control, and support third-party SNMP monitoring interface

2.9.6.4.          Configuration Management

2.9.6.4.1. Activation Center should support activation service configuration management, support activation of integrated products of multiple network technologies and services, including

n   Mobile phone service (3G, 4G, IMS, etc.)

n   VAS (IPTV, etc.)

n   Fixed network services (FTTx, DSL, etc.)

n   MVNO services

n   WIFI Services

2.9.6.4.2. Activation Center should support graphical quick design of order fields and formats

n   Support order field validation rules

n   Support graphical division of combined product orders into single product, and divided network service activation, and further divide into network script

n   Support graphical definition of basic data, such as product category, service type, device type, network equipment type, etc.

n   Complete configure of relationships between orders or between sub-orders, such as the common RollBack relationship: Rollback Order’s rollback operation on the original data, with different handle strategies

2.9.6.4.3. Activation Center should support graphical definition of network script, to be reused in different activated services

2.9.6.4.4. Activation Center should support deployment of multiple versions, and the old and new versions can coexist in the system

2.9.6.4.5. Activation Center should support graphical service time out value, number of retry times, exception handling trigger conditions, result determination, etc.

2.9.6.4.6. Activation Center should support various network devices management

n   Network device’s network routing rules are configured according to device type, resource information, geographic information, segment information, SLA information, etc; the appropriate rules are integrated into the system activation rules, and determines which destination network device will be sent the commands.

n   Support configuration of network device types, network device communication protocols, primary backup and other information

n   Support configuration of network device access control attributes, number of retries, number of time a command is sent, number of connections, working hours, etc.

2.9.6.4.7. Activation Center should support multiple network device templates, such as HSS template, AS template, and support configuration of network device template types, communication protocols, primary backup and other information

2.9.6.4.8. Activation Center should support appropriate plug-in development and deployment tools, to facilitate management of configuration, packaging and deployment of the above.