當工作或學習進行到一定階段或告一段落時，需要回過頭來對所做的工作認真地分析研究一下，肯定成績，找出問題，歸納出經驗教訓，提高認識，明確方向，以便進一步做好工作，并把這些用文字表述出來，就叫做總結。大家想知道怎么樣才能寫一篇比較優質的總結嗎？那么下面我就給大家講一講總結怎么寫才比較好，我們一起來看一看吧。

新醫院的工作總結 醫院信息系統新技術篇一

新系統計劃于8月10晚正式上線運行，各項準備工作要求8月9日前完成。一． 總務科：

1.打印紙采購，型號：a

4、a5（木漿70克紙）2.門診病人信息登記表印刷（2萬張）3.門診導醫工作臺布置 二． 門診部

1.配備導醫人員5名，在門診大廳負責幫助病人填寫登記表。 2.與門診收費處組長協同完成對門診專家、科室掛號排班設置并及時修改。三． 財務科

1.門診收費及藥房人員8月9日18：00做一次全員全流程模擬運行。 2.完成就診卡領取工作，每張就診卡收取病人押金兩元。

3.門診上線日，門診收款結賬改為21：00，結賬后停止收費10分鐘，之后用老系統正常收費，待收到信息科通知后啟用新系統，結賬后老系統所收費用需第二日在新系統里重錄入。

4.門診上線第一日，門診掛號收費及導醫上班時間改為7:30，提前辦理掛號手續。

5．門診上線第一日下午18:00做財務日結，報表由專人負責核對。6.新系統上線后，門診在老系統中的退費，仍在老系統中進行，老系統仍需做日結，并打印日報。四．藥劑科

1.8月10日21：00門診結賬后，將結轉門急診各藥房藥品庫存，各藥房及藥庫當時庫存要導出備份，并打印交相關部門保存。庫存導出后，門急診各藥房老系統庫存將被初始化，各藥品庫存將被設為20000，各藥房與住院相關業務仍在老系統運行，各門診藥房住院藥品銷量將在切換住院系統時統一處理。

2．住院藥房在門診上線后和住院上線前的時期，領藥應在新藥庫系統進行，藥房庫存由微機房根據藥品出庫單在老藥房系統中增加庫存。

3.住院切換日，住院藥房庫存應導出備份，并打印交相關部門保存。 4.住院新系統上線后，在老系統中計費的藥品如需退藥，需由臨床科室開出三聯紅處方，寫明退藥品種，交藥房簽字后，送微機房處理并簽字后在住院處辦理退藥手續。

5.新系統上線前一日完成新老藥品目錄差異的補充錄入工作。 五．護理部

1.完成護理人員工號、權限確認工作。

2上線前完成一次模擬測試工作，要求每病區至少有兩名護士對新系統操作完全學會并較為熟練。

3.住院新系統上線后，在老系統中計費的藥品如需退藥，需由臨床科室開出三聯紅處方，寫明退藥品種，交藥房簽字后，送微機房處理并簽字后在住院處辦理退藥手續。

六．醫務科

1.完成醫生工號、權限確認工作。

2．上線前完成一次模擬測試工作，要求每病區至少有兩名護士對新系統操作完全學會并較為熟練。

七．其它

新醫院的工作總結 醫院信息系統新技術篇二

概述

我覺得自己很幸運，能夠有機會參與到一個全新產品的從無到有的一個過程，如果說可以把這看做是一個項目的話，那么對此有一點

心得體會

在我所在的公司，一個新產品從無到有分為幾個階段： 第一、產品運營提交策劃 第二、技術部門開發 第

三、

每個階段在實施的過程中都會遇到各種各樣的問題，而不同階段所遇到的問題點又不盡相同。但有一點是相同的，那就是每個階段在實施的過程中都會事先定好一個時間節點，以此來保證整個項目的如期進行。

第一階段：產品運營提交策劃

作為產品經理或產品策劃來說，都希望出一個盡善盡美的產品，而老板不會給你做出一個盡善盡美產品的時間，這個時候就會有一個提交策劃的時間點出來，也就是第一階段的時間節點。那么作為產品經理為了能夠如期提交策劃，需要注意以下幾點：

１、控制好需求

需求其實有兩個極端，一個是盡善盡美，盡可能的讓功能更友好，用戶體驗更佳;一個是盡早交付，一切改善性的需求都可以犧牲。

只滿足前者，提交策劃的工期可能會不斷的拖延，因為很多功能的工作量其實是在細節的優化，而不是主要流程的完成。只滿足后者，很可能會出現一個讓用戶很不滿意的產品。那么產品經理就要做到平衡好這兩點。

２、對需求說不

你對一個需求說不，只要這個需求不是一個會造成其他功能依賴的核心需求，就算這個需求后面發現必須實現，你可以補上，總體工作量并沒有增加。但是如果你花資源去完成了這個需求，后面卻發現這個需求是不重要的或者可以簡化的，那你已經浪費了一些工作量。兩者的代價相比，明顯前者的代價比較小。例如小說頻道，之前花費了大量的資源去做小說，功能也比較完善，但是到了后期發現小說的背景與整個產品的背景選擇發生沖突，最后在開發過程中圍繞此問題討論許久之后，決定放棄小說背景。

３、深入了解官方渠道的軟件審核機制

由于在產品設計前期沒有考慮到官方渠道上線的審核機制，導致充值頁面反復駁回，產品技術浪費很多資源去做的充值到后期需要重新設計，并且對用戶體驗造成了很大不便。所以在產品設計之初需深入了解官方渠道的軟件審核機制。

４、整理好需求的優先級

a.確定不變的需求應該先完成，如果策劃去完成了一些功能，結果發現后面的需求要改，那前期的一些工作量已經浪費了。

b.被其他需求依賴的需求應該先完成，只有這樣，才能不擋住依賴它的需求的進展。比如登錄功能，很多登錄后的頁面都需要當前登錄的用戶信息。

c.主流程，或者核心需求應該先完成，改善性的需求應該后完成。比如信息列表頁面，很多功能需要用戶在信息列表里面進行選擇。因此信息列表是核心需求。而在信息列表頁里面一個列顯示格式的美化，這屬于改善性需求。５、不要讓細節影響你的目標

做產品的人很容易沉浸在功能的細節當中，為一些友好美觀的顯示，炫麗的功能或者很酷的設計浪費大把的時間，沉浸在細節當中很容易讓人忘記工期，忘記產品的最終目標。這里不是說不讓你去完善細節，而是這些細節方面的事情等產品核心功能完成之后，有大把的時間可以專注在細節方面。先把核心功能完成是目標。

６、不做一半的功能

如果我們做了2個功能，但是我們每個功能都做了一半沒全部完成，那目前為止我們總計完成了多少個功能?1個? 不是的，完成了0個。一個功能除非真正完成并且通過，不然你永遠不能確定這個功能是不是還有一些遺漏的地方。所以我們做功能的時候，要確保我們在做的功能已經是真正完成了，我們再去接著做下一個功能。

７、風險管控

產品經理應該盡量在早期把所有的風險都列出來，一個一個解決。一個流暢的項目，從前期到后期風險點應該是倒三角形的，就是前期風險很多，后期風險越來越少。而項目管理不暢的，則是一個正三角形，上面風險少，到后期風險就多了。

假設有一個點，你不確定他是不是有風險的，那即使我們在早期把它當做一個風險點重視起來，帶來的代價也遠遠小于在后期等它爆發出來的時候再處理。

例如，我們有一個充值功能，可以用支付寶或網銀或點卡進行充值。這需要調用第三方接口，而跟外部協調都有一個不可控性存在，所以應該把這個風險點在事先重視起來。避免像網銀充值那樣，前期各個環節都增加了此功能，但在后期網銀充值不可行，導致前期很多資源的浪費。

第二階段：技術部門開發 第一階段將策劃如期提交到技術部門之后，接下來就是最重要的產品開發環節。而在此環節中在公司內部提到最多的就是開發的完成時間。

計劃完成時間與合理完成時間：

這個開發的完成時間一般都是計劃完成時間，而軟件開發不是一個可以直接添加資源就可以加快速度的過程，其中包含很多其他客觀因素，例如跟策劃人員之間的溝通，產品流程不通，功能設計不合理，前后功能不一致等。由此導致在這個計劃完成時間之外還隱藏著一個實際合理的完成日期，而在進展整個產品開發的過程當中，其實也是發現這個隱藏的合理完成日期的一個過程。

從管理的角度來講，當然是盡可能的趕上計劃的完成時間。但是因為多方面因素的影響，項目管理是一個欲速則不達的過程。如果這個計劃完成日期早于這個實際合理完成日期，那你越往這個不合理的日期趕，工期內積累的問題就越多導致后期收尾的時候爆發，結果反而連合理完成日期都趕不上。

影響工期拖延的幾大因素：

１、產品需求的不斷更改

影響工期最嚴重的因素就在于產品需求的不斷更改。所以產品經理在技術開發期間，應嚴格避免策劃需求的不斷更改，嚴格按照產品的迭代周期進行開發，避免在技術開發的過程中，不斷的優化產品細節。任何一款產品都不會盡善盡美的面市，都是一個需要不斷優化的過程，所以所有產品的優化方案可等第一版本的產品面市之后，緊接著進行第二版本的優化。以此節約工期。２、未能及早的發現問題

而在產品開發階段雖然出力的主要是技術人員，但是整個產品是否能夠如期誕生，最主要的責任在于產品經理，所以這其實是產品和技術協同發展的一個過程，也就是產品部門依賴外部的一個過程。而大家都知道，內部能處理的問題一般都是小問題，而需要外部人員處理的問題，才是大問題。因為外部人員不受你調配，他應承你的時間不一定是你滿意的時間。即使是你滿意的時間，也不一定真的就能確保在那個時間完成，就算真的完成了，也不一定就達到你想要的效果。

這就要求產品經理在技術開發期間要步步緊跟，及早的發現問題，報告出來并解決。ａ.你應該經常去看一下他們的任務開發到了什么程度，可以的話，讓他運行給你看一下。

ｂ．問一下有沒有什么問題，有什么可以幫助他的。因為很有可能他就有個問題在糾結，而你的出現可能會給他帶來糾結的時間成本，并及時把該問題解決。

ｃ．你在檢查的過程當中，也會有可能發現一些他可能還沒發現的問題，或者跟這個任務相關聯的問題。

任務的完成進度和完成質量，是影響產品上線的一個重要因素。產品經理的一個主要職能，就是幫助每個任務的快速推進。３、開發人員未能看到全盤

在進行產品開發時，經理們能夠很好的分配任務，讓各個員工可以較獨立的工作，這很不錯，但也未必是件好事。因為軟件開發是一個團隊合作的工作，尤其是對于交互性較多的產品，每個人做的事情都有交叉，我做的功能，接下去就要調用你的接口。你做的頁面，接下去就要跳轉到我的。所以就要求每個人，可以重點在自己手頭的任務，但是思路必須是在全盤，大家腦子里面都要經常去想想，整個系統是什么樣子的，我的功能前后的依賴是什么樣的。而產品經理和技術經理平常要引導大家這樣想并且合理進行任務劃分。

第三階段：全面測試、產品上線

產品終于在技術的加班熬夜奮戰中初出茅廬了，每個人的臉上都洋溢著自豪的表情，但此時還未到真正高興的時刻，因為馬上面臨下一個最具劃時代意義的日期――那就是產品的上線日期。

在此階段，工作重點全部落在了軟件測試身上。雖然如此，但可以說沒有一個產品是等一個ｂｕｇ都沒有之后再面市的，也就是說每個新產品的上線都可能帶有幾個?。猓酰?，不影響用戶體驗的?。猓酰纭６脩魧浖南矏鄢潭炔粫捎谶@產品出現幾個?。猓酰缇屯Ｖ故褂?，所以說測試的工作重點不是將所有的ｂｕｇ都找出來，而是要保證影響產品正常使用的功能性以及邏輯性ｂｕｇ是嚴格不允許出現的。其他的小ｂｕｇ可以等產品上線之后統一修復。這就需要所有人員要牢記產品的上線日期，將產品功能性、邏輯性ｂｕｇ完全消滅在產品上線日期之前。

而就管理而言，在有限的時間內，在人員有限甚至短缺的情況下，測試負責人需要考慮的問題如下：

1、測試的設備需求

2、測試的人員需求

3、對測試人員進行培訓

4、測試的具體工作劃分

5、測試報告的提交

在對測試人員進行測試安排時，由于大家不是專業的測試人員，而每個人的工作崗位不同會造成每個人在測試的過程中所關注的點是不同的，這就需要測試負責人要熟悉每個人的特長，揚長避短。引導大家朝測試重點進行針對性測試。所以測試的任務安排以及人員安排是測試負責人必須重視的地方。除此之外，測試負責人還需要考慮的問題如下：

1、當測試人員測試的執行不到位、敷衍了事時該如何解決？

2、怎樣提高測試效率？是否需要將測試的工作具體劃分到完成多少條？

同時測試工作不是單純的部門內部的工作，而是需要與技術部門進行協同合作的一個工作，所以團隊配合就尤為重要，測試負責人一定要嚴格把控好提交測試報告的時間，避免資源閑置。

總結：

經歷了以上三大階段之后，產品正式上線。全公司上下都在為產品的如期面市而感到驕傲與自豪，而作為負責這個產品的總負責人可以稍微松一口氣了。但是在總結整個項目管理的過程中，有幾個管理要點不容忽視。

１、固定的項目組成員、組員潛力、人人看到全盤

固定的項目組成員，這個需求很簡單，但不是所有人都會重視的。正如一個新的策劃或開發者進來并不能夠讓整個項目進展的更快，反而整個進展可能會受到影響。而每個組員都是很聰明的，他必定會有某一特長，作為ｌｅａｄｅｒ要擅長發現組員的才能，將其安排在合適的崗位發揮其特長，如此才會加快整個項目的進展。

再有，再整個項目進展的過程中，要讓每個人都能夠清晰的看到產品的進度，產品以后的發展以及在各個階段每個員工需要配合的工作等。這樣無論是對個人還是對公司，都是比較透明的，都能讓大家明確方向，不致于迷茫。

２、做當前、看后續

當我們把當前的做的迭代的需求，流程，依賴以及其他的疑問理清楚，讓項目組可以順利推進的時候，項目經理不應該再專注在當前的迭代，而是要開始想整理下一個迭代的事情，讓大家在完成當前迭代的時候，不需要暫停在那邊，去等待梳理下一個迭代的問題。

３、項目的小迭代及正確的里程碑要點

項目是不可能一步到位的。把一個大目標分解成每一個小目標，整個項目工期分成若干個短迭代，一個一個的完成。每一個完成的小目標都能幫助你理清整個項目的進度，方向，幫助你審核一下目前的思路是對的還是錯的，出錯了，也能夠及時的調整。

并且每一個項目短迭代最好要列出一份所有人都認同的里程碑列表。并且每個里程碑的完成都要有大家都認同的驗證方式。

比如：分為框架設計完成;分解出來的需求已經可用于開發;子任務劃分完成;子任務已經分配并預估完成;各子任務完成;產品經理檢查通過等。

４、項目的責任感與自我管理

項目經理應該有這個的責任感，你要為這個項目的任何一件事情負責，因為這個事情會影響到整個項目的工期，而你為整個工期負責。比如：我發現現在的項目有一個緊急的問題需要項目組外的人幫忙解決。于是我把郵件發出去，通知ｂ趕緊處理這件事情。幾天過去了，ｂ還沒有處理。我想，我已經把問題說出去了，接下去就是ｂ的事情。那個問題還是沒有解決，我的整個工期受影響了。事后追究起來，我說，我已經發出郵件了，是ｂ沒有及時處理。ｂ說，我事情那么多，我怎么知道這件事情這么急。項目工期受影響了，誰的責任?ｂ嗎?不，是我自己。

作為一個對整個項目負責的項目經理，沒有人會比你更在意項目的進展。讓一個不負具體負責的人去幫你推進你的項目，遠遠不如你自己用心推進來得有效。

５、項目經理是打雜的項目組里面的每個專業成員，他們都有擅長的領域，做他們擅長的事情是他們的快樂。而不屬于他們擅長的事情，對他們來說就算是雜事一般。

項目經理一定要有一個這樣的意識：

項目經理就是打雜的，幫助項目組成員把雜事處理掉，讓他們可以專心的做他們擅長的事情，這樣對項目組來說才是高效的。

“為什么我的手下不能解決這么簡單的問題?如果連這種事情都要我來幫忙的話，那我這個項目經理做來干什么?她當項目經理得了?！斑@種想法千萬是不可取的。

你當這個項目經理的目的并不是管人，指使這人做什么那人做什么。你的目標只是把項目快速推進完成。

新醫院的工作總結 醫院信息系統新技術篇三

網站建成后，根據用戶體驗及外部竟爭條件的變化，網站少不更改，小的更改問題不是很大，如果是大的改動，也就是意味著網站要來個徹底的大換血，改版，那么網站改版本在技術上應注意些什么呢？我在這里總結幾點。

1、新版網站盡量在本地進行改版制作，如果需要在服務器上進行操作的，可以找一個臨時空間，用自帶的三級域名或綁定二級域名，舊版的網站一定不要有任何動作，等新版處理好之后，直接更換掉舊版網站。

2、如果改版過程中涉及更換域名，一定要把舊的域名向新域名做301重定向操作。因為這樣能夠很好的把以前積累的權重傳遞到新域名。并且301要一直做，最好 做1年以上，而且累積了一定時間的域名百度也會有個很好的評價的。如果用同一個域名改版網站，可以去百度投訴中心提交投訴，有很大幾率能夠當天更新快照。

3、在制作新版網站的時候，進行使用舊版網站上的標題、關鍵詞和描述，本身來說，這3個地方對搜索引擎來說影響巨大，因此，在改版時盡量不要改動網站標題、關 鍵詞和描述，這些地方的改動，會導致搜索引擎把你的的網站打入沙盒之中，將會在很長一段時間內，因重新考察你的站點而刪除你網站的排名，無疑增加了你的運 營成本，也會造成客戶的流失，流量直下!

4、界面和布局都可以全部更換，盡量和老網站的目錄層級和結構差不多，百度非常喜歡結構和路徑合理的網站

5、網站新版開發完成后，要上線測試，如果發現問題，立即進行修改。這個時候，老版的系統一定是同步運行的。你可以建一個二級域名指向新系統進行測試，也可以在老系統中發布通知，鏈接上新系統地址，讓更多的老系統用戶參與試用。

6、改為拒絕所有搜索引擎掃描收錄，原因很簡單：新系統的測試域名以后會更改，并且很多頁面seo可能沒有考慮到位。

7、保持新系統與舊系統的url地址上的統一，特別是老版已經被收錄的頁面，如果不一致，將會造成新版上線后流量的大幅減少（我用urlrewrite可最大限度達到統一）。

8、新舊系統切換前，必須要做好網站地圖，并要仔細檢查頁面中是否有死鏈。

9、發一份站點通告或幫助，向用戶說明老系統中的功能，在新系統中怎樣才能找到。

10、在新舊系統并行運行一段時間后，你可以確信新系統已經比較完美后，請找一個在線用戶最少的時候，完成系統的切換（改虛擬主機映射即可，我在后面的文章中會介紹）。

11、在技術實現上，還有一個非常重要的問題，就是將新舊站點的域名信息，寫到一個配置文件中，新系統中所用用到的地址信息，都從配置文件中讀取，在新舊系統切換的時候，你將會發現這么做的好處是多么的有用。

12、一般改版后，搜索引擎都要重新對網站進行考察，原有的外鏈已經失效不起作用了，因此，新網站剛上線一定要更新些內容，高質量的內容再加上外鏈，內容的添加要循序漸進，一定要原創，讓搜索引擎爬蟲有一個通道能重新訪問你的網站，增加蜘蛛訪問你網站的頻率。

13、最后，新系統成功切換替代老系統后，請給系統的每一個老用戶發一封郵件，告訴他們站點已經更新，更新的亮點也要說明，“喊他們回家吃飯了”，呵呵。

不同的切換方式，決定了數據導入時注意事項的不同。

分步切換還是并行上線，是erp系統上線時決策者必須做出的決策。分步切換和并行上線的優缺點分析

在新舊系統切換時，決策者通常有兩種選擇：分步切換和并行上線。

不論決策者選擇何種方式，他都需要明白所選方式的優缺點，以采取合適的準備工作。

分步切換的優缺點

通常，分步切換的方法非常具有實際意義。

通常，企業可以讓財務和庫存管理兩個模塊先切換，隨后銷售、采購、生產等模塊再跟進。這種方法至少具有以下一些好處。容易控制：

相對于所有模塊一起切換的大兵團作戰，這種方式更容易控制。而且財務和倉管部門一般較為嚴謹，第一個月先穩住這兩個部門的陣腳，對于士氣會是非常大的鼓舞。

速度加快：只有這兩個模塊進行切換，在操作上是大大簡化了，系統操作的速度和質量將大大提高。對賬簡化：如果第一個月仍然并行，那么只有財務和庫存管理的新系統和舊系統的對賬就將大大簡化，甚至可以用自動對賬的工具從憑證直接核對。

期初訂單：由于銷售模塊還沒有上線，企業就不需要準備期初訂單了，所有和期初訂單有關的錯誤和問題也可以避免了。關注新訂單、新流程：當其他模塊跟進時，企業只關心嶄新的業務，比如完全新的銷售訂單。我們可以直接用新的流程處理這些訂單。而對于期初訂單，實施者不需要關心處理它們的過程，而僅僅是在財務和庫存管理上核算它就可以了，一段時間以后，它們的影響將自然地結束。

當然，分步切換做法的缺點也是明顯的。

銷售數據不完整：相當長一段時間內，有些信息會丟失或不完整，這主要和期初訂單相關。比如獲利分析的數據將不完整，和期初銷售訂單相關的獲利分析數據就丟失了。不要低估這一點，因為上線后看不到完整的報表，會使不了解情況的領導們非常不高興。因此這個問題一定要在使用前就明確說明。

切換期間拉長：這不能完全說是一種缺點，因為切換期拉長其實分散了工作量，也提高了成功率。但是對于某些條件好的公司，可能因為這一點而選擇更快的全面切換方法。

更多的系統設置：比如要設置兩套物料移動類型，一套是配合銷售訂單、采購訂單和生產訂單的，一套是獨立的。權限也需要做相應的設置。

總而言之，對于實施困難大、訂單執行周期較短的項目，考慮分步切換的方法會有不錯的效果。

并行上線的不利因素 為什么并行是我國企業實施erp時比較喜歡的一種上線方式？ 理由只有兩個字：風險。事實上，選擇并行最主要的理由就是避免風險，而并行這種方式本身就會帶來比較大的風險。并行對于系統切換不利的原因主要有：目的不明、工作量大、對賬困難。目的不明：并行的目的實質上是對新系統的測試，但是用并行來測試系統無疑是非常昂貴的。同樣性質的業務要重復地輸入無數遍，最后查出的差異往往只是輸入上的錯誤，對于系統驗證是毫無幫助的。工作量大：并行無疑加大了所有系統用戶的工作量。巨大的工作負荷加上對于新系統的陌生和恐懼，使得目標越追越遠，最后不得不放棄。

對賬難：對于兩套有不同流程、不同概念的系統，即使不存在會計政策的變更，要完成對賬的難度也是可想而知的。而且對賬不同于審計，如果并行期以舊系統為準，那么新系統最終必須和舊系統完全一致才行，這樣根本無法使用審計中的重要性原則，而只能是完全的核對?？傊?，并行的目的是防止失敗的風險，而事實是它本身成為造成失敗的最重要因素之一。如果采取不并行的上線方式，erp的實施者需要采取更多的防范切換失敗風險的措施，如測試和培訓。

正如上面講到并行的目的是對新系統的測試和驗證，那么如果不并行就必須強化測試。實際上除了對于系統的測試，數據導入相關的測試也不容忽視。如果測試做得不充分的話，并行上線就容易演變成一次實際數據測試，雖然測得非常全面，但是成本太高了。

如果不并行，一定要非常關注切換前期的培訓，特別是對系統實際使用者的培訓。對于是否并行這個問題，目前業界仍然沒有一個放之四海皆準的真理。但筆者希望，上面的分析能對決策有所幫助。

在商務印書館實施管理信息系統過程中，是把分步切換和并行上線兩種方式結合在一起了。商務印書館是逐步上線一個個模塊，而對于某個模塊的上線卻采用的并行的方式，如發行系統。

發行系統的切換特點是：風險大、要求效率高，準備必須充分。所以在正式切換之前，信息中心和實施廠商先期完成了詳細的結構分析，在此基礎上進行數據試轉換，以保證數據切換的順利和成功。在上線新的管理信息系統之前，商務印書館已使用另一家公司的發行系統有3年時間，原系統積累了大量業務數據，發行業務人員在原系統基礎上已能實現庫房管理、批發管理、財務管理等工作。商務印書館為新的發行系統上線確定了以下目標： 1.實現從原北大方正發行系統平滑過渡；

2.發行子系統與商務印書館管理信息系統其他子系統實現無縫的信息共享和統一的業務操作，將本系統生成的數據自動傳遞給其他相關的子系統，避免數據的重復錄入，保證數據的一致性和系統的應用效率。就新舊系統如何切換的問題，信息中心與發行部、實施廠商共同研究，提出三種解決方案。

第一，新舊系統實時并行。該方案要求發行部業務員同步使用新舊兩套系統，系統風險性最小，可以通過新舊系統的對照來驗證系統的可靠性，但業務員工作負擔最大，同步工作要求嚴格。

第二，新舊系統分時并行。該方案要求發行部業務員使用新系統，次日由發行部指定專人將指定的業務區域的前一工作日的業務單據錄入舊系統，這種方案對業務員造成負擔相對比較小，系統風險相對比較低，但是由于業務員隨時可以修改前幾個工作日的單據，所以兩個系統很難同步，同時庫存數據也無法核對。

第三，完全拋棄舊系統。發行部用新系統開展業務工作，完全拋棄舊系統。這種方式相對人工成本小，但存在一定風險。發行部考慮到系統切換的風險性傾向于采用第一種方案，而實施廠商從系統實施的復雜度來考慮建議采用第三種方案。經信息中心與發行部、實施廠商三方協商，綜合考慮各種因素，最終決定采用第二種方案。決定采用第二種方案后，商務印書館對前期數據進行了準備。首先，發行盤庫結束，由信息中心同步備份數據，以保證原始數據的安全性。其次，實施廠商在原來試轉換的基礎上，正式對商務印書館原北大方正發行系統進行數據遷移。再次，實施廠商會同信息中心及發行部相關業務人員對系統切換后的數據準確性進行校驗，并得出結論：對照新舊系統，數據能夠保持一致。根據系統切換的第二種方案，發行部門正式使用新系統，經過三天的系統并行，對照新舊系統，數據能夠保持一致，加之系統并行工作量過大，發行部門決定放棄舊系統，完全切換到新系統進行業務工作。經過近兩個月的試運行后，發行子系統運行流暢，發行部所有的業務工作都在系統的支持下開展。

系統開發完畢，經過反復、周密的測試，由項目負責人將系統重新發布出去，但要盡量保證原有數據完整性，保證新舊系統切換過程中還影響業務部門使用。因此建議先期新老系統并行，待新系統穩定之后再關掉老系統。

五、系統切換

為了保證原有系統有條不紊的、順利轉移到新系統，在系統切換前應仔細擬定方案和措施，確定具體的步驟。系統的切換方式通常有三種，如圖7－3－2所示。1．直接切換

直接切換就是在原有系統停止運行的某一時刻，新系統立即投入運行，中間沒有過渡階段。用這種方式時，人力和費用最省，使用與新系統不太復雜或原有系統完全不能使用的場合，但新系統在切換之前必須經過詳細調試并經嚴格測試。同時，切換時應做好準備，萬一新系統不能達到預期目的時，須采取相應措施。直接切換的示意圖如圖7－3－2所示。(a)。

圖7－3－2

系統切換的方式

2．平行切換

平行切換就是新系統和原系統平行工作一段時間，經過這段時間的試運行后，再用新系統正式替換下原有系統。在平行工作期間，手工處理和計算機處理系統并存，一旦新系統有問題就可以暫時停止而不會影響原有系統的正常工作。切換過程如圖7－3－2（ｂ）所示意。

平行切換通?？煞謨刹阶摺Ｊ紫纫栽邢到y的作業為正式作業，新系統的處理結果作為膠合用，直至最后原有系統退出運行。根據系統的復雜程度和規模大小不同，平行運行的時間一般可在２～３個月到１年之間。

采用平行切換的風險較小，在切換期間還可同時比較新舊兩個系統的性能，并讓系統操作員和其他有關人員得到全面培訓。因此，對于一些較大的管理信息系統，平行切換是一種最常用的切換方式。

由于在平行運行期間，要兩套班子或兩種處理方式同時并存，因而人力和費用消耗較大，這就要時實現周密做好計劃并加強管理。3．分段切換

這種切換方式是上述兩種方式的結合，采取分期分批逐步切換。如示意圖7－3－2（ｃ）。一般比較大的系統采用這種方式較為適宜，它能保證平穩運行，費用也不太大。

采用分段切換時，各自系統的切換次序及切換的具體步驟，均應根據具體情況靈活考慮。通?？刹捎萌缦虏呗裕?/p>

(1)按功能分階段逐步切換。首先確定該系統中的一個主要的業務功能，如財務管理率先投入使用，在該功能運行正常后再逐步增加其它功能。

(2)按部門分階段逐步切換。先選擇系統中的一個合適的部門，在該部門設置終端，獲得成功后再逐步擴大到其它部門。這個首先設置終端的部門可以是業務量較少的，這樣比較安全可靠，也可以是業務最繁忙的，這樣見效大，但風險也大。

(3)按機器設備分階段逐步切換。先從簡單的設備開始切換，在推廣到整個系統。例如對于聯機系統，可先用單機進行批處理，然后用終端實現聯機系統。對于分布時系統，可以先用兩臺微機聯網，以后再逐步擴大范圍，最終實現分布式系統。

總之，系統切換的工作量較大，情況十分復雜。據國外統計資料表明，軟件系統的故障大部分發生在系統切換階段，如圖7－3－3所示。這就要求開發人員要切實做好準備工作，擬定周密的計劃，使系統切換不至于影響正常的工作。

圖7－3－3

故障發生時間

此外，在擬定系統切換計劃時，應著重考慮以下問題：(1)系統說明文件必須完整；(2)要防止系統切換時數據的丟失；(3)要充分估計輸入初始數據所需的時間，對管理信息系統而言，首次運行前需花費大量人力和時間輸入初始數據，對此應有充分準備，以免措手不及。例如，對于一個5 000紀錄的庫存數據庫，如果每條紀錄含200個字符的描述信息，就意味著有1 000000字符必須通過鍵盤進入磁盤，即使操作員以每小時8 000個字符輸入速度，對于一個規模較大的系統，輸入初始數據所需時間也是非?？捎^的。

從舊系統向新系統的切換方式有三種:直接切換、并行切換和分段切換。211 直接切換

直接切換是在確定新系統試運行準確無誤時,立刻啟用新系統,終止老系統運行?？紤]到新系統在測試階段時試驗樣本的不完全性,所以這種方式一般適用于一些處理過程不太復雜,業務數據不很重要的場合或者老系統已完全無法滿足需要的情況。212 并行切換

這種切換方式是新老系統并行工作一段時間,對照新老系統的輸出,并經過一段時間的考驗以后,新系統正式替代老系統。由于與舊系統并行工作,消除了尚未認識新系統之前的驚慌與不安。在銀行、財務和一些企業的核心系統中,這是一種經常使用的切換方式。它的主要特點是安全可靠,但費用和工作量都很大,因為在相當長時間內系統要兩套班子并行工作。213 分段切換

分段切換又稱逐步切換、向導切換、試點過渡法等。它是以上兩種切換方式的結合。在新系統全部正式運行前,一部分一部分地替代老系統。那些在轉換過程中還沒有正式運行的部分,可以在一個模擬環境中繼續試運行。這種方式既保證了可靠性,又不至于費用太高。但它要求子系統之間有一定獨立性,對系統的設計和實現都有一定要求,否則就無法實現這種分段轉換的設想。

第一種方式簡單,但風險大,萬一新系統運行不起來,就會給工作造成混亂,這只在系統小且不重要或時間要求不高的情況下采用。第二種方式無論從工作安全上,還是從心理狀態上看均較好;缺點是費用大,系統太大時費用開銷更大。第三種方式是為克服第二種方式缺點的混合方式,較大系統使用較合適,當系統較小時不如使用第二種方式方便。3 信息系統切換的難點

311 與新系統的模塊功能集成度成正比的復雜性目前開發的信息系統多是分模塊的集成系統。這些模塊和功能之間是相互滲透和連貫的,在組織的日常運作和管理中,具有不可比擬的優點,但在系統切換時系統的模塊和功能越多越復雜,系統切換的困難也就越大,而且難度成倍增加。正像2 條直線相交是1 個交點,3 條直線相交是3 個交點,4 條直線相交就是6 個交點一樣,集成點會隨著模塊和功能的增加而成倍增加。而且即使使用同樣的模塊,不同的組織對其進行不同的配置時,其切換的流程、方式也會有所不同,因此很難得到普遍適用的規則。312 與舊系統的數據、流程割舍不斷的牽連系統切換最重要的工作之一是數據轉換。舊系統的數據一般質量較低也較分散,在向新的信息系統轉換時,運作所需的大部分數據需要通過加工舊系統的數據獲得,因此,系統切換的難度完全取決于舊系統的質量。這里的舊系統,不單指目前組織正在使用的計算機系統,也可以是過去手工操作的業務流程。舊的流程會影響新系統的初期數據,舊流程越不規范統一,系統切換時就越麻煩。313 人力、物力、財力的昂貴代價

系統的切換在時間上應有嚴格要求,在新舊系統切換過程中,組織或機構本身的業務活動是不能中斷的,對于這段時間業務的記錄是使用原來舊系統的一套方式,還是按新系統的要求來做? 這是一個艱難的選擇。適合選擇直接切換方式的情況并不多,但選擇另兩種方式,在某種程度或階段上則意味著新舊系統會并行存在,所有相關人員的工作就會加倍,而兩套數據或記錄的“對接”問題更為復雜煩瑣,系統的切換難度更大。314 人為習慣與思想阻礙

信息系統的切換不僅僅是系統項目開發組的任務,它涉及組織的許多部門和人員。一個信息系統的實施是否成功,取決于組織管理層的權威與能力,取決于部門間的責任與配合,也取決于整個公司的文化。而組織領導層的支持和理解,無疑是成功的前提條件。不幸的是,舊系統和舊流程很混亂的組織,在信息系統實施過程中項目組得到的支持往往也較少。另一方面人們內心深處都恐懼變化,尤其是這種變化的好處還未直接顯現時。在信息系統切換階段,這種變遷會使組織員工面臨一些工作和心理上的負擔,低落或抵觸情緒會造成時間或數據質量的失控,無論哪種情況,對于系統切換而言都是致命打擊。4 成功進行系統切換的關鍵要素 411 細致的規劃

系統切換是信息系統實施階段一個關鍵步驟,要有專門的班子來討論和制定切換計劃,包括切換的方式,切換的起點和期限,切換的步驟和進度控制,資源的配置和人員職責,初期數據的準備工作等。計劃必須經過審定并形成文檔,以備查考。412 領導的重視

信息系統的開發是為了配合組織實現其目標,而組織的領導者作為組織目標的決策者,應對新的信息系統的實施給予相當的重視并提供良好的系統切換條件和環境,更重要的是要學習和理解信息系統所帶來的先進的管理思想和方法, 布置良好的合作與分工,同時對新信息系統的實施充滿信心。413 人員的培訓

所有的信息系統都是人機系統,人是起決定作用的因素。在信息系統開發的整個階段都必須進行人員的培訓,但在新舊系統切換時的人員培訓尤其重要。一是這個階段屬“混亂”時期,僅僅經過試驗性測試的信息系統還未進入實戰狀況,舊的一套系統又還沒退役;二是這個階段參與人員最多,包括新系統開發者、管理者、使用者。不進行必要的人員培訓必然導致系統切換的失敗。

414 組織的重構

新信息系統的實施可能會對組織的機構提出一些要求,包括合并或新增一些機構,并且需要改變原有的管理規則與制度,改變原來的工作模式,創建面向新系統的業務流程和相關制度,包括組織文化,以減少新舊系統之間的沖突與錯位。415 數據的完善

為了使系統能夠完好運行,數據必須完整、準確、一致、及時。新系統涉些及哪數據? 原有中需要改變、補充或完善的數據是什么? 分別來源于哪些部門或功能?切換工作的延誤與“瓶頸”最終都會歸集于數據的整理、變換工作。416 前期工作的質量

系統切換是信息系統項目中第一個“混”不過去的階段,例如可以混過現有流程的分析階段,混過系統測試階段等。系統切換不但混不過去,而且前期工作的所有問題在這個時候都會反映出來,因此必須用務實的態度切實提高前期工作的質量,這樣才能使切換工作比較順利。總而言之,新舊信息系統的切換需要人、技術、管理的協調聯系。新的信息系統取代舊的系統是組織發展的必經之路,是信息化社會組織生存的必然需求。在投入了大量人力財力物力進行信息系統開發后,新舊系統的切換成功,是系統開發目標得以實現的第一抹曙光。

新醫院的工作總結 醫院信息系統新技術篇四

附件2：

新國庫支付系統上線切換方案

為保障新版中央國庫支付管理系統（以下簡稱新國庫支付系統）上線運行，支持中央國庫集中支付電子化管理工作順利開展，第一批試點中央部門平穩切換，按照安全、穩妥、積極、簡易的原則，以系統順利上線和預算單位正常開展業務為目標，我們制定了年中系統上線方案。

一、整體思路

整體思路上，新國庫支付系統上線采取“余額導入”的方式，確保試點部門所有預算單位的全部業務同時遷移到新國庫支付系統辦理，即將試點部門的指標余額（指標-支出）、額度余額（計劃-支出）、可報計劃指標余額（指標-計劃）、非稅收入收繳賬套信息（用于以收定支）等信息導入新國庫支付系統，作為試點部門在新國庫支付系統開展業務的初始數據，支付明細信息、用款計劃明細信息以及除非稅收入收繳賬套以外的賬套信息等歷史數據暫不導入新國庫支付系統。系統切換期間暫停試點部門的國庫集中支付業務（含非稅收入退付），清理、核對、調整、遷移數據。一是在舊國

庫支付系統中清理核對業務數據保證相關口徑不超預算。二是舊國庫支付系統按照相關口徑計算出試點預算單位預算指標的已用金額，將相關口徑指標已用金額按照一定規則扣減到每條預算指標上，將每條預算指標的總額和剩余金額導入新國庫支付系統，用于新國庫支付系統支付指令的指標控制；三是舊國庫支付系統計算出試點預算單位剩余額度，按照新國庫支付系統額度口徑（不分項目）生成后導入新國庫支付系統，作為新國庫支付系統額度控制依據；四是舊國庫支付系統計算出試點預算單位可報計劃指標金額（預算指標-已下達額度的用款計劃）導入新國庫支付系統，用于新國庫支付系統用款計劃的指標控制依據；五是舊國庫支付系統將非稅收入賬套信息導入新國庫支付系統，用于非稅退付用款計劃和請款單以收定支的控制。

代理銀行將試點單位的剩余額度按照新國庫支付系統口徑（不分項目）自行計算并與財政核對一致后導入新國庫支付系統。

人民銀行將試點部門的剩余匯總清算額度導入新國庫支付系統。

系統切換完成后,預算單位恢復辦理國庫支付業務。執行指標、用款計劃、資金支付等日常業務全部在新國庫支付系統中辦理；總預算會計在舊國庫支付系統中處理完整賬務信息，在新國庫支付系統同步記錄試點部門的支出賬務信息和非稅退付賬務信息；對于查詢報表，在新國庫支付系統中暫無法查詢到切換前的支付明細、計劃明細等數據信息和審核流程情況，需要在舊國庫支付系統中查詢，按口徑匯總計算類的報表不受影響。

系統切換過程預計要耗時4天（自舊國庫支付系統停用至新國庫支付系統啟用），在此期間試點部門單位應抓緊完成人員、公用經費拆分等工作，如確實無法按時完成，則可先遷移至新國庫支付系統再做調整。

二、具體方案

（一）基礎數據。

1．單位基礎數據。新國庫支付系統國庫執行單位的單位

名稱、預算碼以預算編制單位為準，組織機構代碼經預算系統和國庫系統核對一致后使用，核對不一致需查找原因，修改預算系統或國庫系統組織機構代碼信息。零余額賬戶名稱、賬號等信息以舊國庫支付系統為準。

2．新國庫支付系統數據分類和碼表按照統一后的基礎數據設定。

（二）業務清理。

對舊國庫支付系統中試點部門業務數據進行核對。由于新舊國庫支付系統業務模式不一致，在舊國庫支付系統中核對和調整業務數據的目標為：保證指標、計劃和支出各階段相關口徑不存在超預算的情況。具體核對口徑如下：

1.計劃是否超指標。按照部門、基層預算單位、預算來源、資金性質、收支管理（基本/項目）、功能分類、項目口徑核對計劃是否超指標。

2.支出是否超計劃。按照部門、基層預算單位、預算來源、資金性質、收支管理（基本/項目）、功能分類、支付方式口徑核對支出是否超計劃。

3.支出是否超指標。按照部門、基層預算單位、預算來源、資金性質、收支管理、功能分類、項目、政府經濟分類（類級）口徑核對支出是否超指標。

（三）預算指標。

1．在途業務處理。指標系統停止發送試點部門的預算指標，確保臨時指標都被替換成正式指標。舊國庫支付系統確保試點部門所有預算指標處理完成，即沒有待接收或接收失敗的預算指標，有問題的預算指標進行退回處理，已接收的預算指標需完成下達，年初國庫集中支付結余指標需完成下達。

2．預算指標導入。新國庫支付系統從指標系統中間區導入已接收成功的試點部門的正式預算指標（當年預算指標和結余調整指標，不導入“二上”預算數），作為新國庫支付系統指標業務數據，并設置為下達狀態。新國庫支付系統從舊國庫支付系統導入集中支付結余指標并置為下達狀態。

3．已用指標計算、導入。舊國庫支付系統根據總預算會計支出賬務信息按照資金性質、預算單位、功能分類科目、預算來源、收支管理（基本支出、項目支出）、預算項目、經濟分類科目（類級科目）口徑生成支出金額信息，系統自動按照以上要素信息與原始預算指標進行匹配，對應到相應預算指標上，作為該條原始預算指標的已用金額。對應規則是：項目支出，相同要素按照先年初預算后調整預算、金額從小到大的順序;基本支出，由于基本支出預算指標區分人員和公用，支出金額信息不區分人員和公用，需要預算單位將基本支出的支出金額信息拆分到人員和公用。拆分方式是：財政生成《指標余額表》（附1）發給部門，部門拆分后報送財政導入新國庫支付系統，導入過程中需進行校驗，校驗要素和金額等信息是否與下發的《指標余額表》一致，確保部門只能在同一科目下的人員和公用間調劑。對于政府經濟分類類級科目支出超預算的情況，先在舊國庫支付系統中調整支出，保證在類級政府經濟分類口徑下無超支，再將支出導入新國庫支付系統與指標掛接。由于指標是明細到政府經濟分類款級科目，因此支出掛接指標時以特定大類下的款級按順序、不超支為默認規則進行逐條掛接。如預算指標的類級政府經濟分類、收支管理（如人員、公用）等信息需要進行調整,部門應履行預算指標調整程序,財政部部門預算管理司局在系統中登錄調整指標。

（四）計劃和額度。

1.在途業務處理。舊國庫支付系統不再接收部門報送的用款計劃，確保試點部門的用款計劃全部處理完成，確保當月及以前月份應下達的財政授權支付額度全部下達給代理銀行，確保沒有在途處理的財政授權支付額度。舊國庫支付系統未下達額度的財政授權支付用款計劃（不管是否批復）全部失效，不再導入新國庫支付系統，試點預算單位需在新國庫支付系統中按照新口徑重新報送。對于直接支付用款計劃，以財政批復的用款計劃為準計算余額，切換至新國庫支付系統。結余計劃全部恢復并將額度下達代理銀行。

2.剩余額度計算、導入。舊國庫支付系統根據已下達的財政授權支付額度和總預算會計支出賬務信息按照新國庫支付系統口徑（預算單位、基本支出或項目支出、預算來源、功能分類科目，不區分項目），計算出財政授權支付剩余額度導入新國庫支付系統，作為新國庫支付系統可用財政授權支付月度用款計劃額度，用于財政授權支付的控制。已批復但未下達額度的授權支付用款計劃，由預算單位在新國

庫支付系統重新申報。舊國庫支付系統根據已批復的財政直接支付用款計劃和總預算會計支出賬務信息按照新國庫支付系統口徑（預算單位、基本支出或項目支出、預算來源、功能分類科目，不區分項目），計算出財政直接支付剩余額度導入新國庫支付系統，作為新國庫支付系統可用財政直接支付月度用款計劃額度，用于財政直接支付申請的控制。

3.剩余可報計劃指標計算、導入。舊國庫支付系統根據原始預算指標和已下達財政授權支付額度計算出計劃可用指標余額表，舊國庫支付系統根據原始指標和已批復直接支付計劃計算出計劃可用指標余額表，導入新國庫支付系統，作為月度用款計劃可用指標余額，用于月度用款計劃的控制。

4.代理銀行額度處理。代理銀行將舊國庫支付系統中試點預算單位已下達的額度按照新的額度控制口徑（預算單位+預算來源+基本支出/項目支出+支出功能分類）生成，與財政核對一致后，遷移到新國庫支付系統作為試點預算單位的剩余額度，用于預算單位財政授權支付的控制。

5.人民銀行匯總清算額度處理。人民銀行將試點部門的已下達匯總清算額度和已清算額度信息直接遷移到新國庫支付系統，用于代理銀行額度清算控制。

6.全年用款計劃處理。試點預算單位不在新國庫支付系統中報送2017年全年用款計劃，全年用款計劃從2018年起編報。

（五）財政直接支付。

1．在途業務處理。確保所有在途財政直接支付業務處理完成。專員辦提前不再接收預算單位提交的中央基層預算單位直接支付申請書，已接收的中央基層預算單位直接支付申請書需處理完成（審核通過或退回），已經過專員辦審核的財政直接支付申請，部門應提前生成財政直接支付匯總申請書報送財政部。舊國庫支付系統不再接收部門報送的財政直接支付匯總申請書，財政部確保所有接收進系統的財政直接支付匯總申請書處理完成（生成財政直接支付憑證發送代

理銀行或取消），財政直接支付工資統發支付申請已全部生成計劃。代理銀行確保試點單位財政直接支付憑證全部處理完成。

2．專員辦審核信息補錄。預算單位需要在新國庫支付系統中補錄專員辦財政直接支付審核材料。

3．財政直接支付明細信息不導入新國庫支付系統。

（六）財政授權支付。

1．在途業務處理。代理銀行不再接收辦理預算單位的財政授權支付業務，已接收的財政授權支付業務處理完成。代理銀行將上一工作日試點部門的財政授權支付明細回單信息發送財政舊國庫支付系統后，不再向財政舊國庫支付系統發送試點部門的財政授權支付明細信息。財政舊國庫支付系統停止接收試點部門的財政授權支付明細回單信息。

2．公務卡信息處理。代理銀行將試點預算單位所有公務卡卡信息和系統切換前兩個月的公務卡消費信息發送到新國庫支付系統。預算單位確保在代理銀行公務卡系統已報銷的消費信息完成公務卡還款。代理銀行停止試點預算單位

使用公務卡支持系統辦理零余額賬戶還款業務。

3．財政授權支付明細信息不導入新國庫支付系統。

（七）結余核定表。

1．在途業務處理。確保舊國庫支付系統中試點部門的結余核定表已經下達并生成正式結余指標。

2.因結余指標不帶人員、公用、政府經濟分類信息，需在新國庫支付系統依據此類指標進行支付時，需人工填入人員、公用信息及政府經濟分類科目信息。

（八）賬務。

1．在途業務處理。系統切換之日上午前，代理銀行將所有直接支付回單、授權支付明細、授權支付日報、匯總業務清單等信息發送財政舊國庫支付系統，人民銀行將清算回單發送財政舊國庫支付系統，財政部確保舊國庫支付系統中試點預算單位的支出賬務和非稅收入收繳賬務處理完成。

2．試點部門的非稅收入收繳賬套信息導入新國庫支付系統，作為非稅收入退付以收定支的依據，其他賬套的信息

（預算內賬套、預算內集中繳庫明細賬套、財政專戶賬套、地方債賬套、社?；鹳~套）不導入新國庫支付系統。

附: 1.指標余額表

2.工作時間安排

新醫院的工作總結 醫院信息系統新技術篇五

關于新系統上線運行的有關事項

中國cdc

一、時間

新系統《國家人口死亡信息登記管理系統》已于2014年1月1日上線，原《中國疾病預防控制信息系統》內《死因登記管理信息系統》將于2014年4月1日停止使用。新老系統并行3個月。請各級用戶在老系統停運前，及時下裁相關報表，新系統僅提供歷史個案數據下載，無歷史報表下載。

二、訪問方式

1、縣及縣以上本級用戶（疾控機構用戶）可使用現有《中國疾病預防控制信息系統》vpn訪問新系統。

ip地址：http://10.249.1.170:94/portal

2、直報用戶（醫療機構用戶）通過internet公網訪問新系統。 ip地址：http://1.202.129.170:94/portal(電信)

http://111.207.225.135:94/protal（聯通）

http://124.127.202.205:94/protal(電信)

三、登錄方式

新系統用戶登錄名稱及密碼與現有《中國疾病預防控制信息系統》相同。

四、報告內容

自2014年2月1日起，2014年死亡的個案使用新版《死亡醫學證明書》（樣式見附件）采集數據，只能通過新系統《國家人口死亡

信息登記管理系統》錄入，屆時，老系統只能錄入2013年死亡個案，2014年死亡個案將無法錄入老系統。

2014年如果還在使用舊版的紙質《死亡醫學證明書》，也需要錄入新系統，可以按照新系統的項目把舊版的內容對照過來即可。已經錄入舊系統的2014年死亡個案不需要再次錄入新系統，將由國家疾控負責導入到新系統。

五、客服電話

如遇到系統登錄、使用等問題請撥打電話 010-58900424 或使用系統內的留言系統。

六、業務管理

各級業務管理員可使用現有《中國疾病預防控制信息系統》vpn訪問新的權限管理系統，用于管理《人口死亡信息登記管理系統》權限，已對現有用戶進行了權限初始化工作，請業務管理員進行核實與梳理。

業務管理員登錄ip地址：http://10.249.1.170:94/uaams

七、新系統使用重點說明

新版《死亡醫學證明書》為達到防偽的目的，設置了較為嚴格的編碼，設置原則是9位組織機構代碼（國標）+年份+4位流水號，為防止流水號重復，需要在錄入數據前先生成死亡證編號，同時進行組織機構代碼關聯工作。具體操作說明見附件。

附件：死亡卡編號生成功能使用說明 說明

《人口死亡信息登記管理系統》即原《死因登記報告信息系統》中死亡卡編號的錄入方式依舊為系統自動生成，但改為由使用單位預生成的方式提前將所需的死亡卡編號生成出來，在填報或錄入死亡卡時依照事先生成的死亡卡編號進行填寫或選擇。

規則

9位組織機構代碼（國標）+年份+4位流水號

組織結構代碼：由國家所提供的各單位登記的機構代碼，稱為國標； 年份：該死亡卡編號被生成時的年份；

流水號：對應組織機構代碼所生成編號的序號。

過程

界面

死亡卡編號生成頁面：

機構信息：圖中“地區”及“機構名稱”為當前登用戶在系統中的地區及機構信息； 組織機構信息：圖中“組織機構代碼（國標）”、“組織機構代碼（國標）所在地區”及“組織機構代碼（國標名稱）”均為已經關聯組織機構信息。

*注：

組織機構信息區域如上圖無信息顯示時說明該單位尚未進行關聯，目前無法進行死亡卡編號的生成。

組織機構代碼（國標）關聯頁面：

篩選條件：提供用戶對“組織機構代碼（國標）”碼表中的“組織機構代碼（國標）名稱”進行模糊查詢；關聯提示：提示用戶該機構是否已經完成關聯操作；默認關聯鏈接：當用戶在下方查詢列表中未找到；機構信息：用戶賬號在系統中所屬的單位信息；組織機構信息：用戶所屬單位所關聯的組織機構（國標）信息；確認關聯按鈕：確認與相應組織機構信息進行關聯。

*注：

1.當用戶在下方查詢列表中未查詢到時，點擊該按鈕將會將當前用戶所屬機構的機構信息插入到組織2.用戶關聯組織機構信息時務必認真仔細，以免關聯其他組織機構后為對應單位帶來不必要的麻煩。

機構（國標）的編碼表中，并與之進行關聯，希望用戶在使用該功能前請先進行認真查詢及確認。

流程

關聯及生成步驟

步驟一：通過功能樹“報告卡管理—>死亡卡編號生成”進入“死亡卡編號生成” 頁面（若該機構已進行過關聯則直接按照“步驟五”所示進行生成即可）；步驟二：點擊“關聯”按鈕進入組織機構（國標）關聯頁面；步驟三：通過篩選條件進行查詢，找到需要關聯的組織機構（國標）信息；步驟四：如果查找到對應信息，點擊對應操作中的“關聯”按鈕即可完成關聯，若在組織機構（國標）表中未找到相應信息，則點擊篩選條件下方的默認關聯鏈接進行默認關聯；

點擊默認關聯時，系統會根據用戶的單位名稱進行一次檢索，如果存在相應組織機構國標信息會彈出提示信息及確認框，用戶可取消默認關聯的操作重新查詢，或繼續進行默認關聯。

步驟五：關聯完畢后，系統將返回“死亡卡編號生成” 頁面，點擊“生成”按鈕開始生成死亡卡編號；步驟六：在彈出的對話框中輸入需要生成的編號數量，點擊“確定”，每個機構下最多可以預先生成100個死亡卡編號，即某機構下已有30個死亡卡編號則下次只能生成70個； 死亡卡編號使用：

編號使用

步驟一：點擊“報告卡管理?死亡卡錄入”進入死亡卡錄入頁面；

步驟二：如下圖點擊“死亡卡編號”文本框后的“選擇死亡卡編號”按鈕進入死亡卡編號選擇頁面；

步驟三：在彈出的“死亡卡編號選擇”頁面中找到對應的編號信息，點擊信息后的“確定”按鈕即完成死亡卡編號的選擇。

*注：死亡卡編號只能在錄入時進行選擇，死亡卡進行保存之后該死亡卡號將從“編號生成器”中刪除，該操作為系統操作不可恢復，請在選擇編號時謹慎操作。

新醫院的工作總結 醫院信息系統新技術篇六

跨上高臺階 步入新境界

-------商丘分行新綜合柜面系統順利上線

商丘分行在接到中原銀行總行大集中項目指揮中心將于2015年9月11日至9月14日實施系統切換上線的命令以后，立即向全分行員工發出了“令行禁止，現場督導；強化責任、任務到人；統籌安排，確保穩定；人員部署，后勤保障。”的號召，強調分行全體員工一定不惜一切代價，同心協力，克難攻堅，確保數據安全移植、新系統成功上線。上線前的三天時間里，全分行全體員工均放棄休息，24小時時刻待命，指令員登陸rtx和指揮系統，時刻關注總行下達的動態和指令，不停地對各支行下達各項指令，終于在9月12日移植成功，9月13日內部員工試營業，9月14日以新系統對外正式營業，當日對公眾宣告了商丘分行新綜合柜面系統順利上線的消息。

這次切換上線和前三輪演練是有區別的，各支行、各條線部門必須要嚴格按指揮中心下發指令規定的時間和要求完成各項切換任務，嚴格按照經過評審和演練驗證的操作步驟執行切換任務，任務完成后要填寫任務單存檔，不準未接通知隨意、擅自提前執行操作指令。為確保系統上線切換期間各項工作得到有效落實，分行領導均分片到支行現場督導。各支行、各條線部門按照分行下發的分時表上報了切換上線人員值班表，要求任務分配到人，責任到人。做到上線工作和日常工作兩不誤，確保業務穩定、人員穩定、思想穩定。分行提前做好了系統切換期間的員工就餐、住宿和交通等后勤保障，做好網點客戶解釋準備工作，以及突發事件應

急處置預案。

周六、周日本來是法定假日休息時間，可是商丘分行的領導和員工一個人也沒有在家休閑娛樂，全在單位加班，不管是指揮中心還是各支行，rtx指令不停地下發，委派會計主管微信群里不時發出新消息，手機的鈴聲不斷地響起，大家都在為上線忙里忙外、不停工作。

9月11日14點，各支行每隔半小時檢查柜面業務辦理情況（各類對賬及差錯處理、查詢查復、第三方簽退等），15:30，再次做了細致檢查，看是否有掛賬，如有掛賬則手工入客戶賬。17點，所有網點和清算中心檢查確認柜面業務是否全部辦理完畢（現金、atm尾箱、憑證）；柜員進行了手工登記現金券別和重空數量、種類，將現金和重空全部上繳給本機構庫管員；現金支票、轉賬支票、銀行承兌匯票，銀行本票、銀行匯票單獨封包和現金一起封箱，其他不移植的舊憑證由委派會計主管和授權柜員在監控下雙人清點核對后封包入支行保險柜，等通知另行上繳；日終后打印網點當日現金和重空余額表各二份，會計主管、支行行長簽字留檔，其中一套上線后交舊憑證時作為銷毀清單附件上交；18點，完成了上述全部工作，柜員簽退、機構關門。9月11日20：00至9月12日8:00，信息技術部及支行指令員對部分終端、打印機和單機版驗印終端進行了升級。

9月12日凌晨2:35-5:00，各支行安排熟悉移植原則的員工根據下發的科目余額表、移植原則等資料，核對科目余額、尾箱憑證、各類明細等（見切換上線參與人員值班表）。7:45，支行所有柜員均到位待命，接通知后所有柜員確認了尾箱，執行了第一階段試營業案例，在11:00完成了第一階

段試營業。11:30-20:00，執行了第二階段試營業案例。執行試營業案例當中，各支行全部使用了新系統真實業務單據填寫、打印，形成真實傳票送后督中心。各支行行長負責檢查，確保了試營業終了時使用的卡、折、存單等介質核對相符。9月12日試營業階段，各支行確保所有柜員指紋登錄新系統，所有終端、打印機、高拍儀、二代身份證閱讀儀、電子驗印均能正常使用。

9月13日7:45，所有執行人員到位待命，各支行按照正常營業配置骨干人員，8:00-10:00按通知進行t+1報表核對。核對中要及時簽收、確認報表狀態，發現問題及時進行了溝通反饋。10:00，按總行通知進行對外試營業。分行培訓師在指揮中心通過rtx、電話等渠道解答支行辦理業務中的疑難問題。10:00-14:00，各支行進行了內部試營業：辦理支行人員卡折分離、定活一本通分離、個人網銀開通、手機銀行開通、個人網銀跨行轉賬、個人存取款、atm存取款等業務。14：00-16:00，辦理了對外試營業，支行辦理了少量客戶業務，支行行長、大堂經理要做好進入營業廳辦理業務客戶量的的疏導和控制，不讓大量客戶同時進入。班后，各支行由行長帶領進行新系統試營業總結，會計主管及骨干要做好心得、經驗的傳帶工作，為次日正式開門營業做好準備。

9月14日7:45，各單位人員到位，開門簽到、報表核對，做好正式對外營業的各項準備工作。9:00正常開門營業，業務骨干首先當班，工作中注意了操作與制度結合，班后各單位由支行行長帶領進行新系統營業總結，會計主管及骨干要做好講解、傳帶工作。分行培訓師在指揮中心通過rtx、電話等渠道解答支行辦理業務中的疑難問題。自9月14日正式對外營業起，每天營業終了均做好了日終處理，嚴格執行柜員簽退、機構關門。每日都登陸t+1報表系統進行核對，班后各單位由行長帶領進行新系統營業總結，發現問題及時溝通反饋。各支行行長或委派會計主管負責每日查庫，確保每日營業終了時，機構庫存現金、重空憑證賬實相符。

通過全體員工孜孜不倦的辛勤努力，截至2015年9月14日，商丘分行的新綜合柜面系統終于順利上線了。這次的新核心系統分為公共業務、負債業務、資產業務、統一支付業務、集中授權業務、集中作業業務、中間業務七大部分，新業務系統將前臺業務受理和后臺集中作業進行了分離，功能更完善、操作更嚴謹，更能防范各種金融風險，使中原銀行商丘分行的操作系統跨上了更高的臺階、步入了新的境界，為商丘分行各項業務的穩健發展提供了全方位、現代化、科學化、正規化的操作系統，進一步增強了商丘分行的服務（會計運營部 王振）

軟實力和綜合競爭力，打造了中原銀行優質高效服務品牌。