|
加拿大电信巨差距 Bell Canada 的母公司 BCE 近期在多个业务部门裁员近 700 人，此外还因部分员工涉嫌伪造办公室出勤记录而开除了“一小部分”员工。
此次裁员是 Bell 近年来最大规模的人事调整之一。加上因考勤相关原因被解雇的几十人，双重裁员引发部分前员工及其律师的质疑，认为 Bell 针对性执行返岗政策，并借考勤调查削减员工人数，这一说法被公司坚决否认。 Bell 表示，作为重组的一部分，共有 690 名员工——约占 BCE 总员工的 1%——被解雇，但未透露因考勤违规被解雇的具体人数。 Bell 发言人 Luc Levasseur 表示：“自去年底开始的组织调整，旨在让团队结构更符合我们的战略目标，目前的裁员是这一进程的延续。这些变化是公司持续运营的一部分，涉及多项举措，包括客户迁移至更稳定、易于维护的光纤网络，以及持续提升运营效率。” Levasseur 补充说，约 230 个工会岗位受到影响，大多数符合条件的工会员工被提供了自愿离职补偿方案。 前IT员工透露：疲于维护旧系统 《多伦多星报》采访了多名现任和前任员工，由于担心失业或影响未来就业，这些员工均要求匿名。一名曾在 Bell IT 团队工作的员工表示，他在 6 月初被裁，原因是其主管称公司正在进行“全公司范围的重组”。 该员工称，过去三年他一直负责维护一个过时的电话平台，尽管该平台已落伍，但因业务所需，Bell 仍在使用。 “团队协作非常令人沮丧。我的经理一直提醒我，这些旧系统的工作并没有正式拨款，但又坚持要求我继续支持，”这位前员工告诉《星报》。“更矛盾的是，我还不断被分配新项目，同时要负责培训印度的离岸员工，教他们如何操作这些老系统。” 他补充说，团队长期工作量超载，因此被裁时感到非常意外。 “我完全没想到会被裁，毕竟我们手头的工作很多，团队本来就人手不足。” 今年早些时候，Bell 开始严查“伪造考勤”行为，经过内部调查，认定部分员工有意篡改考勤记录后，以“正当理由”开除了数十人，通常涉及未达到每周三天回办公室的要求。 BCE 发言人 Luc Levasseur 今年 5 月曾表示：“这些案件涉及有意且反复伪造出勤，包括进入办公室登记后立即离开。每起案件都经过彻底调查，并向当事人出示了明确的违规证据。大多数员工承认自己有意且反复伪造考勤。” 据一名了解裁员详情的 Bell 员工透露，调查发现员工为打卡采取了多种手段，包括在午夜前后短时间内连续刷门禁卡，以记录连续两天的出勤。有些人则会专程到办公室买咖啡（业内称“coffee badging”），或仅使用健身房，随后在家远程办公。 Bell 坚称调查过程严谨，且员工在被开除前均获知违规证据，但代表部分前员工的律师指出，公司此前长期默许管理层对考勤规则“睁一只眼闭一只眼”，如今却选择性执法。 就业律师 Jean-Alexandre De Bousquet 代理约 30 名前 Bell 员工，他曾表示，这些考勤开除本质上是“以正当理由为名的大规模经济裁员”。“实际上，大多数人的主管都知道相关情况，Bell 以前对此视而不见，直到公司觉得不方便才开始处理。” 《星报》获得的 5 月份 Bell 内部邮件显示，公司首席人力资源官表示，在调查发现员工“有意且反复”滥用门禁系统登记虚假出勤后，只有“一小部分”员工被解雇。 一名被解雇的员工表示，她认为这封邮件起到警示作用，显示公司正在紧盯返岗政策，因此她随后调整了行为，更加严格遵守要求。不过在 5 月底，她仍被叫去与人力资源及调查员面谈。 “他们问了我很多问题，我还特意说‘你们不会是质疑我现在的行为吧？因为我现在做得没错’，他们却说‘不是，我们在问你过去的行为’。其实那些问题我早已自觉改正过了，根本不用别人提醒，现在为什么还要被追究？” 她还称，在该邮件发出前，她的主管从未强制执行返岗政策，也没有明确说明具体要求。 “我的经理总是轻描淡写地说：‘我不喜欢事无巨细地管，只要工作完成，几点来几点走我都不管。’” 多名前员工称，他们在被调查和解雇前几乎没有收到警告，也有人说管理层曾明确同意灵活考勤安排，但这些安排后来却成了被指控违规的理由。 Bell 否认了这些说法，称曾默许考勤造假的管理层也已被调查并解雇。 这轮裁员并非 Bell 首次因大规模解雇引发关注。2024 年初，Bell 曾在一次仅 10 分钟的线上会议中，宣布 400 多名工会员工为“冗员”并直接通知解雇，相关工会代表表示。 Unifor 工会称这一做法“极其丢人”，并补充说，管理层只是宣读了解雇通知，“不给员工或工会成员开麦提问的机会”。 |
Copyright © 1999 - 2026 by Sinoquebec Media Inc. All Rights Reserved 未经许可不得摘抄 | GMT-4, 2026-9-14 01:55 , Processed in 0.119343 second(s), 22 queries .
