2009-05-28 37 views
2

我的任務是自動化HR中的一些紙張表格。這最終可能會變成「自動化所有形式」,所以我想以一種長期最好的方式來解決這個問題,並且隨着這個項目的發展,這將是一個很好的框架。在辦公室自動化紙張表格和流程

浮現在腦海中的第一件事情是:

-InfoPath /的SharePoint(我們目前不使用SharePoint現在,也不會是未來兩年的一個選項)

- 工作流基礎(我已經研究過這似乎並沒有太吸引人或適當的)

選項我正在考慮在這一點上:

- 自定義ASP.NET(VB.NET)& SQL Server,它是我的團隊主要寫的東西他們的應用程序。 - 利用Infopath以電子方式創建表單。想知道是否有一種很好的方法將其與定製的ASP.NET應用程序集成在一起。 - 考慮將應用程序創建爲MVC Web應用程序。

我的問題是這樣的:

-Are還有其他的選擇,我可能要考慮? - 那裏有任何入門套件或基於VB.NET的開源項目,這將是一個起點或可以作爲一個很好的參考。在這裏我主要關注工作流程處理。 - 來自那些沿着這條道路走下去的人的任何意見?

+0

謝謝你們!所有的好建議都會牢記在心。 我仍然對這些細節有所顧慮: - 使用Infopath窗體混合ASP.NET編程,或者如果我們不使用SharePoint,應該忘記InfoPath。在這裏,我擔心我會陷入做大量複雜的HTML/CSS來複制幾十個表單。呸!使用Infopath允許我將這些表單創建轉移給其他人。 - 關於記錄(圍繞所有流程包裝我的頭腦),您建議使用什麼工具來記錄或定義他們的流程。也許Visio流程圖? – DeveloperMCT 2009-05-28 20:12:50

回答

5

這聽起來真的很愚蠢,但在我多年來幫助公司實現紙質表單流程自動化的過程中,首先要了解流程。你很可能會發現沒有一個人能理解整個事情。你需要通過這個過程來角色扮演許多路徑,才能讓你掌握它。一旦你提出你的發現,每個人都會感到震驚,因爲他們不知道那是複雜的。以此爲契機進行簡化。

自動化破碎過程只使得它更快搞砸了,並告訴了很多人。

至於工具,我的經驗,我的日期,但嘗試去與一些具有這些屬性:

  • 容易改變的。你將會改變它。所以不要硬編碼任何東西。
  • 可能的修訂控制 - 對進程的更改可能影響或不影響已經在路由中的文檔?
  • 可視化工作流編輯。每個人都想要這個,但他們都會要求你開車。仍然是很好的工具。

不知道這是否有用 - 但自動化流程的成功不是技術。

+2

+1我同意100%。確保你理解整個過程,因爲大多數基於表單的過程過於複雜。在執行之前絕對建議精簡。這不僅會讓你的生活變得更輕鬆,而且當過程花費更少的時間,並且最終變得更加複雜時,你的成功實際上會更高。將破損的流程移至電子版本不一定會使其「更好」或「更高效」。畢竟,它仍然是一種形式。 – 2009-05-28 17:46:59

1

這是稍微偏離主題,但相關的 - 缺陷跟蹤系統一般具有工作流引擎/狀態。 (事實上​​,我認爲Joel或其他FC員工發佈了一些關於使用FB來管理初始電子郵件和恢復過程的內容)

我在做任何編碼或技術選擇之前就建立工作流程的其他建議。你也會希望這是靈活的。

1

由於n8owl提醒我們,自動化混亂產生自動混亂 - 這不是一個改進。許多紙張形式系統已經在幾十年的發展歷程中發展起來,並且可能相當多餘且不規範。一些人士可能爲侵犯他們的個人領地的「與形式搞亂」,所以看你回來;-)

  1. 模型中使用的人的目的是什麼什麼樣的角色形式方面的工作流程;這將當前流程記錄爲基準。獲取的每一步需要多長時間的估計,無論是在工時方面和日曆時間
  2. 理解的聚集,產生的信息化方面的工作流程,並傳遞
  3. 鞏固表格上的信息到一個新的爲最小的工作流程設置表格
  4. 準備好被告知「這是我們一直這樣做的方式,我們不會改變」,並輕輕地(a)驗證他們的感受,(b)解釋如何(c)顯示出具體的益處[與步驟1的基線相比]
  5. 儘可能使用軟代碼;儘可能使用處理規則; Web服務和HTML表單(特別是W/jQuery的)會,如果你有一個Intranet
  6. 提防罐裝包(包括SharePoint),除非你完全確定它們包括組織當前和未來的需求
很長的路要走

祝你好運!

--S