結論からお伝えすると、勤怠管理システムが難しいと言われる理由は、管理しているのが結果ではなく業務プロセスだからです。
と言われてもイメージできないと思いますので、「東京から大阪への移動」に例えて説明します。

東京を出発し、大阪に到着した。
これは結果です。

東京から大阪へ行く方法はどうでしょうか？
移動手段には、例えば次のようなものがあります。
・飛行機
・新幹線
・高速バス
・在来線
・自動車
・バイク
・タクシー
・自転車
・徒歩
・上記の組み合わせ、などなど

同じ「東京→大阪」でも、その「行き方」（プロセス）は無数にあります。

勤怠管理システムを設定するうえで参考になるのが、就業規則です。
しかし、就業規則に書いてあるのは結果です。
「始業は9時、終業は18時」
「残業代を支払う」
「有給休暇を付与する」

勤怠管理システムで管理するのは、業務プロセスです。

時刻の記録方法（打刻）と計算方法
→ 9時前の打刻でも9時から勤務とする？
→ 打刻を忘れた場合の修正方法は？（申請必要？）
→ 遅刻した場合の処理方法は？

残業の手段と取り扱い
→ 残業する場合は申請・承認が必要？
→ 始業時刻前の時間は早出残業とする？
→ 始業時刻をずらして実働8h超を残業とする？

有給休暇の取得方法と処理方法
→ 有給休暇の申請・承認を行う？
→ シフト作成時に有休を反映？
→ 半日有休を取得した場合の残業計算方法は？

同じ規則（結果）でも会社ごとに管理方法（業務プロセス）は異なります。
また、勤怠管理システムの製品選定では、実績が重視される点もこの視点で説明ができます。

多くの実績がある製品では、その経験から、さまざまな業務プロセスに対応すべく、機能が実装され続けています。
開発されて間もない製品では、ケーススタディが乏しく、ゴールへの手段が限られていることが多くあります。
○○には対応しているが、御社の運用に合わせた管理は標準機能で対応できないということを良く耳にします。

勤怠管理システムは、結果だけを見ていると簡単に製品が開発でき、設定も容易に見えますが、業務プロセスに視点を合わせると、非常に多く複雑な機能が必要となり、設定は複雑となります。
製品選定、初期設定、管理者としての運用など、勤怠管理システムに関わるときは、「結果ではなくプロセスを管理している」という視点を念頭に置いてくださいね。