雲端工作術
各類應用示範
案例故事
逃離惡夢
關於 Ragic
你有遇過那種大家公認的電腦高手、軟體達人、或 Excel 小天才嗎（或者你自己就是）？
可能從沒讀過資訊、資管相關科系，大學唸的可能就是文組，但新軟體都學得好快，或許對 IFTTT、Notion、Trello、ClickUp 這類工具如數家珍，也或許是任何事情都能做成超精美 Google Sheets、Excel 公式超強、總是可以把數據統整得井井有條……
這類「資訊小天才」，在職場上很吃香，我們會想像這份能力，能為他既有的工作加分。不過，如果只是軟體產品愛好者、Excel 重度使用者，感覺上比較像能幫我解決表格問題的「強者我同事」，要直接大變身，變成某家公司的專職 IT、MIS、工程師……好像還是有點落差。
不過，我們最近就聽到了這樣的故事：一個不會寫程式、對電腦工具很有興趣、剛畢業幾年的年輕人，遇上 Ragic 這樣的 No Code 開發工具，進而變成公司專職 IT ，一肩扛起公司系統升級任務的故事。來看看吧！
雖然讀傳播科系，但 Bill 很早就發現自己對於資訊管理很感興趣，在大學時期修過幾堂課，有自己的一套資訊處理概念、邏輯，要在 Google 試算表、Excel 上設計出各種複雜的公式也難不倒他。
Bill 在畢業前負責系上畢籌會的財務計算，利用他擅長的 Google 試算表設計公式、串接表單，讓對帳的過程能夠更順利。不過有個 Google 沒法解決的問題，有點困擾：很多時候畢籌會討論好預算，確定要支出款項的時候，會有原先默不出聲的同學們跳出來說「我不同意支出這筆錢」。
這也是他認識 Ragic 的契機——Ragic 是市面上少數免費版就具備簽核功能、輕量使用也很輕鬆的表單工具。用了 Ragic 每一筆支出在表單上都必須經由同學們主動按下同意或拒絕簽核，系統上也會有明文記錄，自然就能大大減少後續可能發生的爭議。
Bill 在畢業之後找到了一份與學歷專業相關的工作——為公家機關撰寫文案與圖卡設計的社群企劃小編。
機關內部會有一套貼文審查的 SOP 必須遵循，舉例來說：為了確保政策宣導資訊傳遞的正確性，完成的圖文都須經紙本方式上呈。在執行的過程中，上呈的流程跟關卡可能會異動，有時一篇貼文最多需要經過七個人的審核。
為了配合單位的紙本格式，Bill 會從自己習慣使用的 Google 試算表把貼文內容複製、再貼到指定的標準 Word 審查表格式，稍加排版再列印出來上呈。但凡內容需要修改，也就必須重複一次「在 Google 試算表修改貼文 → 貼到 Word 排版」的過程，再重新印出來上呈。
隨著修改的可能性增加，一則貼文花費往返尋找資料、複製貼上的時間也越來越多，他想到了 Ragic 的合併列印可以解決他的煩惱：「假如今天貼文要修改，就到 Ragic 上面編輯，改完之後就直接輸出合併列印，就不需要再做多餘的步驟。」省去了慢慢在 Google 試算表上找資料，再反覆手動貼到 Word 的過程。
某次，專案中加入兩位外聘的專業社群顧問，也需要參與審查的簽核流程。但是，外聘顧問並不是公司內部的人，該如何將他們的意見、簽名放在紙本文件上？實際上有很多困難需要解決：「要郵寄？或親自送過去？用 PDF 簽名對一般使用者而言又太過麻煩，而且又有兩位顧問，簽名該怎麼整合在同一份紙本上？」
這個時候，Ragic 的簽核功能就派上用場了。只要將顧問們的 E-mail 設為簽核關卡、發起簽核，寄送寫好的貼文資料給他們，並以信箱開啟簽准，就能填寫意見、簽名。表單上只要加入簽核公式欄位，並套用合併列印，就能在紙本文件上呈現來自外部顧問的意見與簽字了。
Bill 說：「我無法改變單位既有的紙本需求、很難讓簽核流程全部電子化，但是我能讓 Ragic 符合既有的 SOP 標準流程，讓我自己工作上方便。」
在 Ragic 修改設計並不是什麼麻煩的大工程，只要簡單拖拉欄位、按下儲存設計就能隨心所欲調整表單，就算常常更改流程也不怕：「畢竟標案內容的異動性與彈性都很高、需要留意的事項也會越來越多，該如何達成單位的需求、又要確保不搞砸，就一定要有一個好的工具來協助自己。」
搭配 Ragic 改善工作流程後，只要寫完貼文就可以一秒開始送審，不需要再把時間浪費在找資料、改貼文跟排版：「節省下來的時間就可以去處理更有意義的事了。」
結束社群小編的工作之後，Bill 來到了一間成立了 30 年、客製化生產團體服的公司——衣的藝術。
Bill 被編入公司的資訊部，而他的職責就是一個人建置適合公司 130 人使用的系統。對於這個最終目標，他主動提供給公司的第一階段目標是： 2 個月上線報價系統、2 年內完成所有系統。
據 Bill 所述，公司成立已經 30 年了，其中卻有 20 幾年都在尋找一份適合內部流程的系統，但找了眾多廠商 Demo ，就發現各家 ERP 完全無法符合公司的需求，就算要請廠商客製化開發，也很難找到有人願意接下他們的案子。
舉例來說，Bill 處理的第一個需求——將報價單從 Excel 轉換成系統，就有讓人傷腦筋的複雜規格。
在處理定價時，會先由總公司定期隨著原物料的浮動調整各項製造項目的價格。調整完畢後，再將定價的 Excel 檔案發給旗下的門市、再列印成紙本。
對於這種不同步的更新方式，Bill 提到曾經發生的實際情況：總公司更新定價之後，門市沒有及時更新紙本，等到發現定價本缺了某些項目之後，才發現正在用的是好幾個月前的版本。
而每個門市收到定價之後，會讓設計師以人工比對的方式查詢價格、輸入資料，這也產生了「人工錯誤」的風險——只要時間一長、工作量一大，稍微閃神，就難免會發生錯誤的情形。
將報價系統搬到 Ragic 之後，得益於雲端資料庫的特性，總公司只要在資料庫更新定價，旗下所有門市都能在表單上「無縫接軌」，用新的定價製作報價單。這樣一來，總公司就省去發送 Excel 定價本的步驟，更不用擔心門市沒有及時更新、用到舊定價的狀況。
另一方面，透過連結與載入，設計師也不再需要手動輸入價格。透過動態篩選來選擇製造方式，讓設計師省去翻找 500 多項的定價的時間，也不用再人工計算，直接由系統算出正確的單價。這樣一來，大大減少設計師計算疏忽的可能性，也進一步提升專業性。
不過，這樣的轉換過程也不是一帆風順的，對於設計師來說，要從相對自由、隨時可以調整報價，方便給客戶一些彈性的 Excel，轉換到相對標準、SOP 化的「系統」，當然也會有一些意見、疑慮。
會不會不夠自由、操作會不會很複雜……這些轉換到系統時常見的疑慮，也不免俗地讓 Bill 在建置系統的初期遇到一些阻礙。
實際上，因為 Ragic 並不是一個非常「硬性」的系統，要修改表單的設計十分容易，耗時也不用個幾分鐘，再加上 Bill 也考量到跟使用者有所互動才能更快速建立一個值得信任、好用的系統。因此，他決定直接建立一個 LINE 群組，選擇用更密集的步調，與使用者一來一往交流意見。
為了促進使用率，首先應用他的專業製作了一系列圖卡，說明 Ragic 的導入與基本操作，再將這些資訊發到群組：
累積了一定的使用率，收到使用者回饋之後，Bill 會根據這些意見調整表單的細部設定，並依據調整的內容，製作圖卡、發布更新日誌，來讓同仁都能快速吸收資訊。
舉例來說，門市很常有「單價試算改數量」的需求：向客戶提供不同數量的商品報價，讓客戶決定是否用更優惠的價格多做幾件衣服。在過去，設計師可以直接複製 Excel 檔，直接更改裡面的價格，但到了 Ragic，使用者需要每一個數量都重新連結與載入，反而會覺得不順手。
為了避免錯誤報價，Bill 最終加上了條件式格式與輸入檢查的設計，在編輯資料時如果發現錯誤的件數，就會以紅底的方式警示需要修改，也要排除錯誤之後，系統才會允許儲存。
這種即時、敏捷的系統開發，也曾經招致一些疑問：「沒有 IT、軟體開發會創一個群組的，都是每個月開一次會、提出需求然後一次改……」
然而，對於 Bill 與 Ragic 來說，這些所謂的「需求」其實都是短時間之內就可以改完的小問題。像是後續有設計師反應，希望系統能再提供一些彈性，例如：希望某個商品價格能有一些浮動的空間，Bill 就透過條件判斷解鎖單價欄位，加上一個數值欄位做加減，來讓使用者直接在最終金額做調整。
這些大量、卻簡單的繁瑣細節不需要累積在一個月、一度的例會中慢慢解決，而是隨時提出並馬上修改設計，讓系統與公司內部的使用者能在短短兩個月內步上正軌。直到現在，Bill 還是會時刻關注公司內部使用者的回饋，針對需求即時調整適當的設計。
隨著這樣的策略，Bill 能感覺到公司內部對於 Ragic 的態度變得更積極：「只要可以滿足使用者的需求，同仁也可以越來越理解為什麼需要做某些的限制與要求，也會更樂於主動提出系統的建議。」
看完 Bill 展示報價系統之後，我們很好奇的是：他並沒有實際接觸過各部門的工作，像是這種報價單，或是將在下一階段上線的 CRM 的配置、樣式，他是如何進行設計的呢？有問過相關部門的人員嗎？
「其實一部分是照著公司既有的模式設計，先滿足他們現有的需求，再去看其他現成的模板、系統有什麼樣的欄位。」Bill 接著說：「可能問了相關同仁，他們也沒辦法直接講出一個標準，因為過去並沒有制定明確的 SOP。」
對於這種「大家心目中都沒有什麼最佳流程」的情況，Bill 的第一步往往都是先把公司目前設計好的 Excel 表、紙本單拿出來看，先把主要需求做好，後續再慢慢最佳化。開始最佳化時，獨門祕訣就是上網惡補各種系統的影片、教學課程。「上 YouTube 看看不同產業跟需求的系統長得怎麼樣，大概會有什麼樣的功能。畢竟我也不是資訊的人，沒看過其他 ERP 或 CRM 長什麼樣子，也沒有用過，但背後的邏輯都是一樣的，就是表單、就是資料庫，所以透過這種方式去了解。」
除了職涯歷程之外，我們同樣也非常好奇 Bill 成為 IT（資訊技術人員）之後的一些個人經驗與心得，因為我們通常也會把 IT 視為一種很會寫程式、很高深莫測的職位、部門，但面對 Bill 這樣「非典型」的 IT，我們也很好奇，突然跨入一個大家印象中需要一定門檻的領域，周遭的人們有沒有感到驚喜或疑惑？
Bill 說，現在的職場上，大家其實不太在意你的「方法」，只要能夠弄出一套系統，而且系統能夠達成期望的效果跟目的，就不太會有人質疑你的能力，不會單獨以「是否會寫程式」這點來評斷。
這段話不僅僅是 Bill 個人的經驗，也與衣的藝術在尋找系統時的經驗相符：面對複雜的問題與需求，遍地找不到適合的系統商時，Bill 與他熟悉的 Ragic 確實就是一個適合的方法，只要能達成這個目的，Bill 當然也是一名合格的 IT。
看過 Bill 設計的報價系統，以及他描述公司同仁對 Ragic 的興趣提升不少，我們也相信衣的藝術進一步轉型、全面電子化的日子指日可待。
分類: 案例故事, Ragic 職涯故事
