一個月薪水被A走6000元,是誰佔了社工便宜?

一個月薪水被A走6000元,是誰佔了社工便宜?

我們想讓你知道的是

台北市社工工會表示,每位社工的薪資平均被A走了6000元,以10人來算,每年就有72萬元資金流向不明。但一名熟悉非營利組織財務狀況的人士表示,這可能是由於「政府也在佔機構便宜」。

文:李修慧|圖表設計:黃彥翔

中華民國新女性聯合會承接台北市「家庭暴力暨性侵害防治中心的」(家防中心)的委託案,負責輔導家暴受害人。但近期卻傳出薪資浮報、違法解雇社工等爭議。台北市社會工作人員職業工會(台北市社工工會)25日第三度為社工召開記者會,要求社會局詳加調查。

而這次新女性聯合會勞權事件中,最初引起爭議的「薪資回捐」在社工界早就不是新聞,但熟悉非營利組織財務狀況的人士表示,這可能也與政府將服務「外包」給民間非營利組織,卻壓低成本有關。

新女性聯合會每個月浮報6000元,一年可能多賺72萬

《蘋果日報》報導,25日,台北市社工工會集結全台各地社工工會,聚集台北市政府舉行記者會。

許多非營利組織都會接政府的「委託案」或「補助案」,通常政府的契約中會嚴格規定這些專案所需聘用的基本人數(幾位社工、幾位督導等),也會寫明會支付每個人多少費用,有的也會編列行政費,而這些費用大多是看收據、領據「實報實銷」。

去年12月間,新女性聯合會的8名社工發現收到的薪資,與組織從政府那裡請領的薪資不符,向管理階層反應後,卻遭到打壓,甚至被解雇。【註1】

勞權大事紀
Photo credit: 關鍵評論網 黃彥翔

台北市社工工會理事長沈曜逸表示,雖然新女性聯合會核發的薪資與當初跟社工約定的薪資相同,但新女性基金會巧立名目把社工人員的薪資報高,再以其他作帳形式流回機構中。

以8名社工中以薪資差額最大的社工舉例,每個月就差了6200元,檢驗每位社工的落差,平均約6000元,以10人來算,每年就有72萬元資金流向不明。

單位(元) 新女性聯合會向政府請領的金額 社工實領金額
底薪 38000 28588
伙食津貼 1800 1800
專業加給 3000 2400
風險津貼 2000 2000
年終獎金/月 3799
總金額 44800 38587
差額 組織浮報了6213元

沈曜逸進一步指出,新女性聯合會之所以能夠這樣巧立名目浮報薪資,與社會局委託經費預算編列採「總額制」有關。

包括加給、津貼等必須付給社工的人事費,在政府與非營利組織的契約中,稱為「專業服務費」。台北市政府目前有明文規定,「專業服務費應全數用於人事費,不得流用」,但沈曜逸表示,2018年8月這個規定曾經修改過,修改前,並沒有明文寫道「不得流用」,只寫出每名員工可以請領的總額上限,如「保護性社工員5萬127元、專案負責人5萬5855元」。這樣的「總額制」,讓機構可以把原本應該給付給社工的人事費,挪作他用。【註2】

《苦勞網》報導,沈曜逸說,「總額制」一開始的目的是為了讓機構可以針對不同年資、表現給予社工不同薪資,給予機構彈性運用的空間,但卻因為沒有相對管理與查核制度,讓一些機構可以在裡面上下其手,以巧立名目的方式,先將薪資報高,再以其他作帳的形式回流到帳目中,社會局單憑機構提供的核銷清冊,根本無法暸解真實狀況,進而損害社工權益。

目前台北市勞工局,已經協同社會局介入調查,將在4月2日公布調查結果。沈曜逸呼籲,社會局應全面檢討目前的總額制度,還給社工員健全的職場環境。

這次與機構產生勞權爭議的陳姓社工私下受訪表示,他們拿到的薪資跟當初進公司、面試時談好的一樣,嚴格來說,「它(指新女性聯合會)沒有A我們的錢,應該是A家防中心的錢,有種偷藏私房錢的感覺。」

陳姓社工指出,過去之所以沒有發現實領薪資跟家防中心補助的薪資不同,是因為薪資「3個月核銷一次,我們對數字也不太敏感,他們要我們簽『領據』的時候其實沒有防心(社工領到薪資後,要簽領據,機構會拿這些領據去跟家防中心請領費用,實報實銷)。機構也説,實際上到年終會給你們年終獎金。」但陳姓社工表示,他曾耳聞同事提到,浮報的金額會拿去「繳房租、水電費、電話費,因為家防中心給的行政費只有30萬。」

不過陳姓社工也強調,「這個案件還在調查中,我的說詞比較是我個人的想法,薪資方面還是尊重調查結果。」

「薪資回捐」到底是什麼意思,有多嚴重?

但其實,台灣的非營利組織(如基金會或協會)像這樣扣下政府標案中規定要給員工的費用,已經是常態,甚至發展出一個特定名詞,叫做「薪資回捐」。

律師呂秋遠曾投書《蘋果日報》,描述最典型的「薪資回捐」狀況,「就是面試的時候,說好3萬2000元的薪水,到了發薪日,以為扣掉正常的勞健保,還會有3萬1000元,但存摺卻只有2萬9000元。喔,還有一張捐款收據,證明這位社工捐了2000元給自己服務的機構。這就是所謂的回捐。」簡單來說就是非營利組織強迫員工捐錢。

根據監察院的報告,現今薪資回捐的樣態不只如此,除了「強迫社工捐款」、「強迫社工認購義賣商品、園遊會票卷」以外,還有「從『專業服務費』中扣除雇主應負擔之勞、健保」。

薪資回捐圖
Photo credit: 關鍵評論網 黃彥翔

而回捐的狀況究竟多普遍?曾任職NPO的立法委員吳玉琴發文表示,2017年12月辦理社工政策規劃會議時,會中衛福部坦言,2016至2017年間共接收到19件薪資回捐案,地方政府補助案14件,中央補助案5件。

至於回捐的金額,《NPOst公益交流站》引述衛福部2017年的調查指出,回捐的金額大多落在1000到4000元之間,但監察院的報告提到,台北市社工工會曾説,他們聽過回捐的最高金額是一個月1萬1000元。

政府是NPO的大金主,沒有編列「行政費」只好想辦法摳員工

但為何許多非營利組織,不願意把政府提撥的費用直接給員工?這些浮報的錢去了哪裡?

一名熟悉非營利組織財務狀況的人士受訪指出,非營利組織之所以形成這樣的陋習,可以歸因到政府的給付不足。他表示,討論非營利組織的財務時,可以分成「直接成本」和「間接成本」,前者就是「這件事需要的社工、交通費等」,後者則是指「行政資源的成本,會計作帳、幫忙核銷、理事長幫忙支援案子等,就是我們俗稱的『管理費』」。

可是,不是所有政府單位,都願意提供間接成本,「就看縣市政府的財政能力,有些就沒有給,有些財政能力更緊縮的,連專案的成本都沒辦法給足,叫你50%要自籌(自籌是指,假設整體計畫費用需要100萬,政府只給50萬,另外50萬要求機構自行籌措)。組織只好想辦法從政府給的錢裡『浮報』一些下來,支撐行政管理運作。」

該名人士表示,過去大環境較好的時候,「機構可能覺得這是它的『使命』,就算是政府給付不足,它還是靠自己的基金會來撐。但當整個大環境的資源緊縮、捐款減少,基金會就沒辦法像以前一樣把它吃下來。」

《報導者》報導,政府經費可能佔許多非營利社福機構整體財源的一半以上,甚至在許多中小型機構會超過7成、8成。整體而言,政府正是非營利組織的大金主。

該名人士就說,「現在某個程度有一點政府在佔便宜,覺得反正你不做有別人要做。」「更暗黑的是,機構不敢把真實成本呈現給政府,因為它如果呈現真實的成本,財務績效差,可能就會影響下一年標這個案子的順位,所以想把一些成本吸收掉。」

【註1】這次勞權爭議不只「薪資回捐」,陳姓社工表示,他們8人反應薪資問題後,組織管理階層還以為他們向家防中心陳情,於是開始縮減員工福利、打壓他們。所有打壓行徑中,最令人難以接受的,是一名社工家住新北市淡水,卻突然被調往桃園,而且只給1個星期的交接時間。

台北市社工工會認為這是「不當調職」,陪社工前往勞動局申請裁決,也在臉書發文要求停止打壓,並附上7名社工的合照(不包含該名被調職到桃園的員工)。但3月18日,這7人突然被叫進辦公室,主管要求7人一個小時內收東西離開,明天不用再來上班。

新女性聯合會常務理事黃碧芬表示,之所以突然解雇社工,是因雙方協調過後,已經調整讓「專業服務費」全用來支付社工薪資,但社工還是在上班時間貼文指控聯合會,不得已之下,才用《勞基法》12條規定的「如有重大侮辱,可以不用預告解雇勞工」終止勞動契約。不過,台北市勞動局表示,解雇行為已經違反《勞基法》第12條,應立即改善。

【註2】沈曜逸説,雖然根據過去的規定,「專業服務費」如果沒有用完可以挪作他用,但新女性聯合會仍有於法不合的地方,因為新女性聯合會讓員工簽的領據,跟實際給予社工的金額不符。

延伸閱讀:

新聞來源:

核稿編輯:羊正鈺


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡