echinagov
黃以寬
首先界定一下，本文的「流程」是指業務流程。一般來說，業務流程與資訊系統的關係是這樣定義的：首先，資訊系統必須滿足一定的業務流程要求；其次，資訊科技可以用來幫助和促進改進流程。實現這兩層關係可以說是資訊系統建設比較理想的目標。
關於第一層關係，一般沒有什麼異議；但說到資訊科技對於流程的「反作用力」方面，就觸到了電子政務相關方面的敏感神經。畢竟，電子政務應用的「流程」，是關乎政策、體現法律、法規的東西，非同小可。所以，為了將政策、法規變成資訊系統，「流程」設計者和it人員常常引經據典、不厭其詳，恨不得這些「流程」能機械化地變成程式**。若說到流程的變化，則大都採取「能不變就不變」的迴避態度。以至於在業界有這麼一種通行的做法：在某一時間點由雙方以正式文件方式來個「一刀兩斷」——設計按照該時間點以前的「流程」進行，而在該點以後的「流程」變化就不予理會。這種做法的潛台詞是：你需求都沒定，叫我怎麼做？所以經常可以看到這樣的現象：昨天，it人員還在虛心地了解和研究需求；今天，就開始埋頭造車，從此對需求的變化——包括對流程的變化——不聞不問，斬釘截鐵。
挑出需求截止點的做法本身沒有大錯，相反，它是需求管理的乙個通常做法，是資訊系統工程的階段性的體現。但我們對待「流程」變化(也就是需求的變化)的態度決定了我們採取這個做法的實際效果。如果我們對業務流程和資訊科技不作任何的前瞻性分析，只是一味迎合、模擬現有的流程，就會陷入應付需求變化的泥潭中。這種情況並不少見：按照某種流程設計的資訊系統，在還沒有驗收，甚至還沒實施的時候，就遭遇「流程改變」的「政策風險」，宣告前功盡棄。應了一句俗話：「計畫沒有變化快」。
的確，「流程改變」正是現階段電子政務專案共同的「政策風險」。今天的電子政務建設，已經不能墨守成規、閉門造車了。在需求主導、便民親民的旗幟下，「流程」這玩意兒不是誰想不變就不變的了，而且有越變越頻繁的趨勢。從政治上說，這種「政策風險」，正是反映了政治體制改革和**職能轉變的過程，是值得我們歡迎和擁抱的。
在這種形勢下，我們有必要重新審視對於「流程」和「流程變化」的態度。對於**部門這一需求主體來講，為了提高行政效能、改進服務，經常性對「流程」進行某些變化(當然有時可能要忍受變化帶來的痛苦)，乃是大勢所趨。
一旦持定這種態度，放開眼界，我們便可以發現：其實已經有諸多的成熟的技術產品和管理思想來支援流程的易變性：在技術上，有各種中介軟體和平台產品，允許我們對應用系統中的「流程」進行不同程度的調整，使開發出來的資訊系統是乙個「活」的系統；在管理思想上，有迭代式的過程思想，指導我們在有「流程風險」的情況下進行系統建設。大膽地學習和使用這些新的技術和管理思想，可以使電子政務建設各方把精力放到對流程的調整、優化上，而不僅僅放在流程的實現上。
所以，今後在發現有「流程」改變的需求時，大可不必一驚一乍地發出「誰動了我的流程？」的質問。因為動動流程，從技術上來說，並不是什麼可怕的事情。可怕的是我們對待流程變化缺乏應有的態度和準備。
誰動了我的PID
1，pid是乙個閉環控制演算法。因此要實現pid演算法，必須在硬體上具有閉環控制，就是得有反饋。比如控制乙個電機的轉速，就得有乙個測量轉速的感測器，並將結果反饋到控制路線上，下面也將以轉速控制為例。2，pid是比例 p 積分 i 微分 d 控制演算法。但並不是必須同時具備這三種演算法，也可以是pd,...
誰動了我的PID
1，pid是乙個閉環控制演算法。因此要實現pid演算法，必須在硬體上具有閉環控制，就是得有反饋。比如控制乙個電機的轉速，就得有乙個測量轉速的感測器，並將結果反饋到控制路線上，下面也將以轉速控制為例。2，pid是比例 p 積分 i 微分 d 控制演算法。但並不是必須同時具備這三種演算法，也可以是pd,...
誰動了我的Config
概述 國內主要網路裝置的廠商是思科和華為為代表的國內和國外廠商。這些廠商的網路裝置的交流作業系統的名字不同，操作的命令也不一樣，但是實現的機理是一樣的。下面就以思科的網路裝置為例來做介紹，其它廠商的也類似。思科的網路裝置的作業系統主要是iso，即cisco internetwork operatin...