在「流程驅動新增長」飛書計畫新產品釋出會上，銳捷網路資訊資源部總經理張洪丹分享了銳捷網路在產品創新的同時，做了哪些流程管理上的創新。
「選擇飛書計畫，是因為它不只是簡單的任務工具或計劃工具，而是一款面向流程的協同工具。」張洪丹說，「如今，銳捷各業務部門已經自己動手在飛書計畫上搭建了 100 多個業務系統，每周有 5 千人在飛書計畫上展開工作，我們每周產生的計畫數據量超過了 2 萬條，並且每天執行 10 萬次的自動化進行數據的傳輸。」
以下是他的演講全文。
業務極速拓展
銳捷面臨什麽挑戰？
各位嘉賓，大家下午好。我是銳捷網路資訊資源部總經理張洪丹。很高興今天能夠參加飛書計畫的新品釋出會，也很高興能夠與大家分享銳捷在過去兩年使用飛書計畫的一些心得。我的主題是從 IPD 到 IPD+，用流程打造場景爆品。
首先，簡單介紹一下銳捷網路公司。銳捷是首批進入國家創新型企業行列的公司，至今已經成立二十多年。在全球範圍內擁有八千多名員工，業務範圍覆蓋90多個國家和地區。經過多年的打磨，我們的產品得到了市場和客戶的廣泛認可。比如在中國市場，我們的無線產品連續五年出貨量第一，雲桌面產品在去年的市場份額也是第一，在交換機領域位居第三。
透過這些年的不斷努力，銳捷為各個行業提供了場景化的解決方案。從最初的基礎網路到後來的安全營運，再到終端管理等各個維度，我們都為客戶提供了差異化的解決方案，幫助各個企業進行數位化轉型。
前面說到，銳捷是一個創新型企業。創新其實是一個老生常談的話題，那銳捷的創新和別人有什麽不一樣呢？簡單總結就是「將技術與套用充分融合，創造性解決客戶問題。」
一方面，銳捷在福州、蘇州、成都、南京等地設立了 8大研發中心，研發人員占比超過 55%，擁有授權發明專利 1000+項。另一方面，說捷一直以來堅持的「場景創新」，也就是：真正深入到使用者千變萬化的套用場景中，找到「一針捅破天」的痛點， 進而提供極簡的解決方案。銳捷的產品方案廣泛套用於各個行業和領域，其中企業客戶服務超過 1W 家。
隨著業務極速拓展，客戶型別越來越多，客戶期望越來越高，銳捷面臨的挑戰也越來越大。我們每年立項 100 多個研發計畫，每個計畫都涉及到銷售、產研、供應多個團隊的協同，大的計畫涉及幾百人的協作，每個產品線有不同業務規則和要求，對於中高端產品和分銷流水線產品，其流程和邏輯是完全不同的。
如何確保新產品一上市就能成功？怎樣保障計畫組成員基於整體計畫目標進行推進？更重要的是，如何在計畫過程中提升和保持各個團隊的協同效率和水平？我想這些都是今天所有企業高管們需要思考的問題。
作為 IT 從業者，我相信今天在座的很多人也是做 IT 的。估計大家的老板會問你：研發領域的數位化到底該怎麽做？你現在的系統流程機制水平如何？如果可以，那如何繼續保持？如果不行，那你到底打算怎麽改進？你的路徑和規劃是什麽？很多人寫 BP 時一定會被問到這些問題。
希望透過今天的分享，能夠為大家提供一些有價值的思考和啟示。謝謝大家。
以客戶為中心的
流程建設是基石
這個問題對於我們來說也是同樣的，因此我們這幾年一直在探索，不斷地探索。簡單分享一下我們解決問題的一些思路和方法。
首先第一個點，我們一直在保持以客戶為中心的流程建設，這是我們的基石，這是不會變化的。實際上，多年前我們就開始了以客戶為中心的 IPD 流程建設。最初的 IPD 流程主要偏向於產研側。那麽什麽是產研側呢？就是指從產品立項到釋出的整個過程，偏重於產研側的管理。
但是你會發現，這種管理方式其實離市場還是比較遠的。那麽，如何能夠更好地貼近使用者，以客戶為中心呢？所以我們需要將流程前移，前移到市場端，前移到客戶端。這樣整個流程就從原來的 IP 流程向前擴充套件，擴充套件到現在已經包含了需求工程、需求管理概念、工程技術、語言技術創新等流程。
到今天，我們已經沈澱出了 28 個二級流程和 90 多個三級流程。實際上，這基本實作了 IPD 向 IPD+階段的過渡。這是我們關於 IPD 的思考。僅有流程是不夠的，流程要怎麽執行呢？流程如何才能發揮作用呢？如何才能高效且有品質地執行這些流程，其實這是我們要思考的問題。
因此，我們需要具備三個能力來解決問題，一個是協作自動化。
首先，我們需要透過 IT 工具來促進各個部門，特別是跨團隊、跨職能團隊的協作，減少低效和不品質的人工工作，這是第一方面。
第二方面是流程的標準化。我剛才提到一個 IPD 計畫團隊，大約有幾百上千人。這些人從客戶需求的理解開始，到整個實作過程，甚至到釋出過程，釋出之後給使用者使用。只要大家的目標一致，這就需要很多標準化。
第三個是數據的一體化。需要透過 IT 手段打通產品設計、開發、生產、銷售的每一個環節，這樣才能保障和實作全生命周期的管理。
這三個能力部份，其實也是我們兩年前與飛書共同探索的一部份。
今天我將透過一些具體案例來分享，而不是講大道理。IPD 流程的建設這個話題太大了，我會更多地講一些我們認為做得還不錯的地方。
首先談一下協同決策。所有企業都會關註研發過程中的關鍵決策，尤其是 IPD 流程，涉及硬體相關的流程，每個角色都至關重要。這裏有多個所謂的 DCP 和 TR 決策點，這些決策點往往決定了商業的成功與否。
以前這種方式通常透過線下會議、信件等方式進行，需要類似於 PMO 或 IPMD 的秘書角色來推動整個決策過程。因為硬體決策需要很多部門參與，包括產品側、銷售側、市場側、供應鏈、財務等多個評委。在這個決策過程中就很復雜，可能會遺留很多待辦事項或風險項。所有的風險項和待辦事項必須在決策 OK 之後才能繼續執行。使用線下方式往往會導致決策時間過長，組織協調成本過高，甚至有些風險未被關閉，影響流程品質。
基於此，我們需要找到一個好的工具來解決這個問題，依靠人工方式永遠無法提高品質和效率。
因此，我們在飛書計畫上將決策矩陣植入系統中。這樣，評委無需透過信件或線下方式進行審批，而是可以線上化地進行審批。同時，我們將評審要素植入系統中，評委可以根據要素進行評審，評審完成後系統會自動生成評審結果。我們還引入了移動化審批，解決了領導在外出差、見客戶時的快速便捷審批問題。
第二點是問題閉環。我認為這個非常重要。因為在整個決策評審過程中，會產生大量的待辦和問題，必須全部解決後才能繼續執行。在問題閉環過程中，如果評委有問題，可以生成一個工單，工單會指定相關負責人跟進解決。我們要求所有問題都必須解決後，流程才能繼續執行。這大大改變了原來的工作方式，確保待辦事項真正得到解決。此外，還包括一鍵拉群功能，方便在有問題時隨時討論。
總的來說，一個好的工具不僅僅是匯總和傳遞資訊和內容，更重要的是承載業務的最佳實踐，提高整體品質和效率。我認為這是一個好的工具。接下來分享第二個話題，我們提到的 IPD 走向 IPD+。這個「+」的第一個需求是整合需求管理流程。
大家可能覺得需求管理流程沒有那麽復雜，這是一個很通用的詞。其實需求管理流程包括兩個大部份， 一個是透過市場端的輸入，即客戶的原始需求收集，這是一大部份。第二部份是我們熟悉的產研側的需求規劃和實作。做硬體的都知道，兩者之間不是一對一的關系。
客戶的原始需求可能會對應多個產品規劃需求，最終釋出的產品版本可能更復雜。這種一對多的關系，如果整個鏈條處理不好，很容易出現問題。什麽問題呢？
讓端到端流程
像一張數位地圖一樣
指引業務戰鬥的方向
前面好的市場需求沒有被產品規劃。沒有規劃，就沒有走到市場端，就沒有去提升你的產品，這會造成多個部門之間的溝通協作問題。許多推拉通的討論，甚至專項活動等都會出現問題。
所以整個端到端流程其實還是蠻復雜的。在銳捷，在構建所謂的需求端到端流程過程中，我們也一步步與飛書探索，我在這裏分享幾個小經驗。
第一個是廣開言路：我們認為收集需求就像招聘人才一樣，先要有數量，然後再有品質。所以我們在飛書計畫裏搭建了一個所謂的需求送出通道。大家都可以透過這個通道反饋客戶的問題，包括客戶的情況、建議等。這不局限於市場人員或銷售人員提，所有人都可以提。我們還設立了一些獎勵機制，鼓勵大家多提需求。這樣做的目的是希望沒有直接在一線的同事能夠更好地了解客戶的聲音，更貼近客戶。
第二個是客戶九問：在需求上來之後，怎樣提升需求的品質呢？我們把自己定義的「客戶九問」邏輯植入到需求表單裏。透過這個表單，可以讓提需求的人在提需求時站在客戶的視角，展現客戶的真實場景。比如，客戶具體遇到了什麽問題？頻率如何？這個問題到底給客戶造成了什麽具體損失？透過這種方式，確保每個人在提需求時品質提高，同時節省了大量需求傳遞過程中解釋和轉譯的時間。
最後是流程互鎖。什麽是流程的互鎖呢？剛才提到的 1:M:N 的關系怎麽解決呢？
我們利用飛書計畫的流程引擎，把需求從收集、分析、規劃、實作直到釋出的所有相關階段，全部植入到一個流程裏。這樣可以透過後台的數據看板監控需求的所有動態。可以看到哪個需求被接收了，哪個需求正在開發中，哪個需求已經釋出到版本裏了，以及客戶的使用情況。需求做到完整的閉環，實作需求端到端的數位化跟蹤閉環管理和端到端流程建設。
總結一下，就是要圍繞流程目標打通每一個環節的斷點，同時呈現流程中業務的真實狀態。透過數位化營運手段和方法指導業務改善。
透過飛書計畫
構建一體化的效率飛輪
大家都知道研發工具的好壞決定了研發效率。研發工具覆蓋了整個產品生命周期，比如硬體研發涉及的工具特別多，軟體也是一樣。研發工具由許多專業系統構成，包括任務管理、公司管理、Bug 管理、計畫管理、預算管理等。這些工具之間的對接越復雜，使用者體驗就越糟，執行流程和效率也會受到很大制約。
所以，業務上需要什麽呢？需要一個具備高協同性和高整合性的綜合平台來支撐整體業務需求。
因此，我們以飛書計畫為中心，透過它來連結所有專業的研發系統，讓這些專業系統能夠專註於其專業領域，從而最大化地提高效率，構建一體化的高效體系。那麽具體如何實作呢？
首先，我們透過飛書計畫強大的整合能力，將上遊和下遊涉及到的所有研發系統整合聯通起來。這裏的整合聯通，並不僅僅是簡單的數據對接，而是重新設計了業務活動級的流程。比如，我們可以在計畫管理系統中發出指令，傳達給下遊的 PLM 等研發系統，使得下遊系統可以自動化地執行。這樣就極大地改變了原先研發工程人員需要跨系統操作的問題，整體上大幅提升了效率。
第二個要點是自動化場景的實作。每個企業在流程中都會有自己獨特的場景和需求，那麽如何解決這些問題呢？我舉個例子，前段時間我們引入了需求樹的概念，這個概念非常復雜，但這是我們的一個特殊需求。
於是，我們透過外掛程式的方式將需求樹嵌入到計畫管理系統中，這樣便捷地解決了我們的特定需求。這裏我想總結分享的是，今天我們談到的系統整合，已經不再是簡單的 API 數據對接，而是基於業務場景和業務活動進行重新創造和變革。
飛書計畫是一款
面向流程的協同工具
就我剛才提到的下遊自動化作業，這是一個典型的案例。
回顧今天大會的主題，我覺得我們與飛書計畫合作的這兩年多時間，正是銳捷 IPD 建設的高速期。選擇飛書計畫不僅僅是為了任務管理、計劃管理等，更重要的是我們認為飛書計畫是一個面向流程的協同工具。它能將我們 IPD 價值流上的上下遊流程及相關角色有效連線起來。這樣我們可以從全域視角審視業務發展，這是最核心的目的。
接下來我想展示一組數據。這組數據反映了我們在與飛書計畫共創過程中獲得的一些分析結果。我認為這個工具非常好，因為我所在的 IT 部門有自己的 IT 計畫管理和需求管理。
我們也搭建了一個系統，我讓我的同事按照說明書花了三到五天時間搭建完成。現在我們使用這個系統後，發現它非常有趣。因此我將飛書計畫工具推薦給全公司。今天展示的數據是全公司使用的數據。我們公司各部門共搭建了 100 套業務系統，有五千多人在使用這些系統。這些系統上已經承載了兩萬多個計畫，不僅是研發計畫，還有其他各種計畫都在管理中。
這組數據背後的意義是什麽呢？我想分享的是，這意味著先進的數位化工具真正實作了生產力的釋放。以前，業務需要提需求，找 IT 部門排隊，申請資源，進行評審。如果 IT 部門無法及時響應，就會影響業務的發展。
有了這個工具之後，使用者可以根據自己的需要隨時調整流程，不再依賴 IT 部門。他們可以根據需要進行適配。這是第一步。其次，對於 IT 部門來說，不需要重復開發一百多套工具，節省了成本和時間，可以把精力放在數位化建設、流程建設，甚至是 AI 研究領域。
因此，IT 技術已經從 IT 部門的專有能力轉變為整個組織的通用能力。未來，組織中的每個人都可以使用數位化工具解決自己的問題。我認為這是一次效率的變革。希望銳捷與飛書計畫繼續攜手前進，借助數位化工具為 IPD 註入新的活力和無限可能性。謝謝大家。
