現在很多論述BSM觀點之中，都強調流程的重要性，對于流程化的重要性，如事件、變更、故障管理，很多人認為這些流程缺一不可，但實際上很多用戶流程并不全面，那他們就不能實現BSM了嗎？

實際上，流程是否重要這個問題同用戶的認識有關系。通常情況下，人們習慣用一種簡單的模式來達到管理的最終要求。在BSM實施過程中，流程化的建設是一個長期的過程，用戶能夠成功的并不多。比如國家電網這個用戶，他們的流程化管理實際上僅僅做好了把事件管理流程。雖然流程建設是一個長期的過程，但是我們并不是說流程不重要。實際上，流程很重要，流程告訴我們的是事情走到哪一步，相關的人才能做哪件事，可是這些都需要基礎的，如果很多問題沒有解決，直接上ITSM的十個流程，那就會缺失流程存在的必要性，就是為了流程而流程，這樣做只能使工作復雜性大大增加，這就使很多用戶就會有抵觸情緒。這是因為，如果要把流程作得很規范，如果要按照標準制定流程，就需要有事件經理、發布經理，知識庫管理人員等相關的職責崗位，這就需要對崗位進行分級，而這個分級過程是在搭建管理體系過程時逐步細化下去，每個崗位的職責是什么。這些工作是必須要做的，如果只是簡單地把概念性的東西推廣給用戶，不幫助用戶制定事件經理的責任，流程的制定就很難推行。而且還有很多反復。
如果按照流程化解決問題，很多時候會造成目前國內用戶處理問題的不適應。比方說，流程化規定要先記錄后處理，但很多企業都是先處理后補單，這時就需要IT運維系統廠商考慮清楚流程設計如何，流程應該如何實施，而不僅僅是做相關的咨詢服務?，F在國內IT運維系統方面的問題是做咨詢的廠商太多，而把問題落到實處去實施的廠商太少。實施很耗費時間，尤其是流程化的建設是要隨著基礎平臺的不斷完善而螺旋型上升的。比如事件管理的定義需要隨著基礎平臺細化而不斷細化，然后把事件流程隨之細化，再然后把相關問題進行更加全面的分類，完善問題管理流程，在這樣的基礎之上還要相應的細化變更管理等等。所以，IT運維的流程化運作不僅是推廣觀念，而是需要同用戶進行密切溝通，否則用戶不能有效使用起來。目前看到很多情況，用戶買了產品，作了很多咨詢工作，結果IT運維系統卻無法應用。目前國內用戶進行IT運維最好的方法是用戶自己建立流程。他們只需要找一個平臺，再找一家咨詢公司來分配相應的崗位職責，并結合實施過程中的問題實時改變就可以完成這項工作。這樣的流程才是實際從用戶需求出發的，適應用戶需求特點的流程。否則簡單地談流程重要性，沒有意義，我們需要的是看目前的IT運維走在哪個階段，然后再實施這個階段相應流程。

目前國內用戶很多都能做到的就是事件管理，最多的就是事件的接單、傳單、處理，再好一點的就是知識庫的記錄（但是知識記錄使用也較少，因為底層管理還比較薄弱）。而問題、變更則是依靠制度以及可以執行的管理方法。很多企業買了很多IT運維管理的產品，但是實施的時候卻發現這些產品用不起來，最終自己來實施流程化管理。

BSM的實施要注意兩方面的問題，一是企業實施BSM為了提高IT部門價值，提高地位，在做BSM也要循序漸進。如果BSM的效果想要讓領導重視，想要在BSM上作出成績，那就必須分析若干個核心致業務，把業務流轉過程透明。比如北塔財務系統，先搭建基礎平臺，然后根據核心業務對IT進行管理。其次要同業務部門進行協調。我們可以先做一個業務系統的管理模型框架搭建，把這里面能夠涉及到業務的所有元素搭建好，讓每一個過程透明，比如業務系統使用人數、每個人的業務流量、分布在內網的位置、這個系統的平均故障響應時間、平均無故障運行時間等等，這些數據在第一時間清晰地展示在領導面前，而且通過業務系統框架可以層層點擊，對所有信息可以進行詳細的查詢，比如物料系統，多少物料運出，做了多少單等等這些都是領導所關心的問題。如果這些可以通過透明框架呈現給領導，那么領導才能夠關注并重視這套系統的價值。

IT管理部門在業務系統中所起的作用很重要，但是IT部門經常以故障的眼光看問題，看到的都是出了問題怎么辦。比如財務系統現在2000人在使用，CPU負載達到了40%，預計明年一萬人使用，CPU負載90%以上。這個時候如果IT管理人員告訴領導，系統哪部分容量不夠，需要擴充，領導明白情況后就能批準。而另外一個相反的例子是某電網公司需要購買一臺小型機，因為這臺小型機已經使用了三年，所以需要更換。如果領導問到具體的更換原因的時候沒有看到具體的使用數據，IT管理者沒有相關的小型機需求數據呈現給領導的話，領導一般不會批準更換。
BSM的核心觀念是IT建設以及運維同業務部門要有交互，北塔軟件在這個理念的基礎上強調業務模型透明化，讓業務部門同IT部門有共同語言，大家能夠統一視角。這樣短期內搭建業務模型，看到成績，領導大力支持。這樣才能把所有業務系統梳理清楚，則IT部門的地位將有顯著提升。